1700455633
public void goodLooking（）{
1700455634
1700455635
System.out.println（this.name+”–脸蛋很漂亮！”）；
1700455636
1700455637
}
1700455638
1700455639
//气质要好
1700455640
1700455641
public void greatTemperament（）{
1700455642
1700455643
System.out.println（this.name+”–气质非常好！”）；
1700455644
1700455645
}
1700455646
1700455647
//身材要好
1700455648
1700455649
public void niceFigure（）{
1700455650
1700455651
System.out.println（this.name+”–身材非常棒！”）；
1700455652
1700455653
}
1700455654
1700455655
}
1700455656
1700455657
通过这样的重构以后，不管以后是要气质美女还是要外形美女，都可以保持接口的稳定。当然，你可能要说了，以后可能审美观点再发生改变，只有脸蛋好看就是美女，那这个IGoodBody接口还是要修改的呀，确实是，但是设计是有限度的，不能无限地考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。
1700455658
1700455659
以上把一个臃肿的接口变更为两个独立的接口所依赖的原则就是接口隔离原则，让星探AbstractSearcher依赖两个专用的接口比依赖一个综合的接口要灵活。接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。
1700455660
1700455661
1700455662
1700455663
1700455664
设计模式之禅 [:1700453919]
1700455665
设计模式之禅 4.3 保证接口的纯洁性
1700455666
1700455667
接口隔离原则是对接口进行规范约束，其包含以下4层含义：
1700455668
1700455669
❑接口要尽量小
1700455670
1700455671
这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则，什么意思呢？我们在单一职责原则中提到一个IPhone的例子，在这里，我们使用单一职责原则把两个职责分解到两个接口中，类图如图4-3所示。
1700455672
1700455673
1700455674
1700455675
1700455676
图4-3 电话类图
1700455677
1700455678
仔细分析一下IConnectionManager接口是否还可以再继续拆分下去，挂电话有两种方式：一种是正常的电话挂断，一种是电话异常挂机，比如突然没电了，通讯当然就断了。这两种方式的处理应该是不同的，为什么呢？正常挂电话，对方接受到挂机信号，计费系统也就停止计费了，那手机没电了这种方式就不同了，它是信号丢失了，中继服务器检查到了，然后通知计费系统停止计费，否则你的费用不是要疯狂地增长了吗？
1700455679
1700455680
思考到这里，我们是不是就要动手把IConnectionManager接口拆封成两个，一个接口是负责连接，一个接口是负责挂电话？是要这样做吗？且慢，让我们再思考一下，如果拆分了，那就不符合单一职责原则了，因为从业务逻辑上来讲，通讯的建立和关闭已经是最小的业务单位了，再细分下去就是对业务或是协议（其他业务逻辑）的拆分了。想想看，一个电话要关心3G协议，要考虑中继服务器，等等，这个电话还怎么设计得出来呢？从业务层次来看，这样的设计就是一个失败的设计。一个原则要拆，一个原则又不要拆，那该怎么办？好办，根据接口隔离原则拆分接口时，首先必须满足单一职责原则。
1700455681
1700455682
❑接口要高内聚