1700455564
searcher.show（）；
1700455565
1700455566
}
1700455567
1700455568
}
1700455569
1700455570
星探搜索美女的运行结果如下所示：
1700455571
1700455572
––—美女的信息如下：–––––
1700455573
1700455574
嫣嫣–脸蛋很漂亮！
1700455575
1700455576
嫣嫣–身材非常棒！
1700455577
1700455578
嫣嫣–气质非常好！
1700455579
1700455580
星探寻找美女的程序开发完毕了，运行结果也正确。我们回头来想想这个程序有没有问题，思考一下IPettyGirl这个接口，这个接口是否做到了最优化设计？答案是没有，还可以对接口进行优化。
1700455581
1700455582
我们的审美观点都在改变，美女的定义也在变化。唐朝的杨贵妃如果活在现在这个年代非羞愧而死不可，为什么？胖呀！但是胖并不影响她入选中国四大美女，说明当时的审美观与现在是有差异的。当然，随着时代的发展我们的审美观也在变化，当你发现有一个女孩，脸蛋不怎么样，身材也一般般，但是气质非常好，我相信大部分人都会把这样的女孩叫美女，审美素质提升了，就产生了气质型美女，但是我们的接口却定义了美女必须是三者都具备，按照这个标准，气质型美女就不能算美女，那怎么办？可能你要说了，我重新扩展一个美女类，只实现greatTemperament方法，其他两个方法置空，什么都不写，不就可以了吗？聪明，但是行不通！为什么呢？星探AbstractSearcher依赖的是IPettyGirl接口，它有三个方法，你只实现了两个方法，星探的方法是不是要修改？我们上面的程序打印出来的信息少了两条，还让星探怎么去辨别是不是美女呢？
1700455583
1700455584
分析到这里，我们发现接口IPettyGirl的设计是有缺陷的，过于庞大了，容纳了一些可变的因素，根据接口隔离原则，星探AbstractSearcher应该依赖于具有部分特质的女孩子，而我们却把这些特质都封装了起来，放到了一个接口中，封装过度了！问题找到了，我们重新设计一下类图，修改后的类图如图4-2所示。
1700455585
1700455586
1700455587
1700455588
1700455589
图4-2 修改后的星探寻找美女类图
1700455590
1700455591
把原IPettyGirl接口拆分为两个接口，一种是外形美的美女IGoodBodyGirl，这类美女的特点就是脸蛋和身材极棒，超一流，但是没有审美素质，比如随地吐痰，文化程度比较低；另外一种是气质美的美女IGreatTemperamentGirl，谈吐和修养都非常高。我们把一个比较臃肿的接口拆分成了两个专门的接口，灵活性提高了，可维护性也增加了，不管以后是要外形美的美女还是气质美的美女都可以轻松地通过PettyGirl定义。两种类型的美女定义如代码清单4-6所示。
1700455592
1700455593
代码清单4-6 两种类型的美女定义
1700455594
1700455595
public interface IGoodBodyGirl{
1700455596
1700455597
//要有姣好的面孔
1700455598
1700455599
public void goodLooking（）；
1700455600
1700455601
//要有好身材
1700455602
1700455603
public void niceFigure（）；
1700455604
1700455605
}
1700455606
1700455607
public interface IGreatTemperamentGirl{
1700455608
1700455609
//要有气质
1700455610
1700455611
public void greatTemperament（）；
1700455612
1700455613
}