1700455700
1700455701
1700455702
图4-5 修改后的图书查询类图
1700455703
1700455704
提供给管理人员的实现类同时实现了ISimpleBookSearcher和IComplexBookSearcher两个接口，原有程序不用做任何改变，而提供给公网的接口变为ISimpleBookSearcher，只允许进行简单的查询，单独为其定制服务，减少可能引起的风险。
1700455705
1700455706
❑接口设计是有限度的
1700455707
1700455708
接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个“度”如何来判断呢？根据经验和常识判断，没有一个固化或可测量的标准。
1700455709
1700455710
1700455711
1700455712
1700455714
设计模式之禅 4.4 最佳实践
1700455715
1700455716
接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个规则来衡量：
1700455717
1700455718
❑一个接口只服务于一个子模块或业务逻辑；
1700455719
1700455720
❑通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；
1700455721
1700455722
❑已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理；
1700455723
1700455724
❑了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。千万别，环境不同，接口拆分的标准就不同。深入了解业务逻辑，最好的接口设计就出自你的手中！
1700455725
1700455726
接口隔离原则和其他设计原则一样，都需要花费较多的时间和精力来进行设计和筹划，但是它带来了设计的灵活性，让你可以在业务人员提出“无理”要求时轻松应付。贯彻使用接口隔离原则最好的方法就是一个接口一个方法，保证绝对符合接口隔离原则（有可能不符合单一职责原则），但你会采用吗？不会，除非你是疯子！那怎么才能正确地使用接口隔离原则呢？答案是根据经验和常识决定接口的粒度大小，接口粒度太小，导致接口数据剧增，开发人员呛死在接口的海洋里；接口粒度太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
1700455727
1700455728
怎么准确地实践接口隔离原则？实践、经验和领悟！
1700455729
1700455730
1700455731
1700455732
1700455734
设计模式之禅 第5章 迪米特法则
1700455735
1700455737
5.1 迪米特法则的定义
1700455738
1700455739
迪米特法则（Law of Demeter,LoD）也称为最少知识原则（Least Knowledge Principle,LKP），虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
1700455740
1700455741
1700455742
1700455743
1700455745
设计模式之禅 5.2 我的知识你知道得越少越好
1700455746
1700455747
迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义。
1700455748
1700455749
1.只和朋友交流
[
上一页 ]
[ :1.7004557e+09 ]
[
下一页 ]