六大设计原则（下）

四、接口隔离原则
定义： 类间的依赖关系应该建立在最小的接口上。
理解：建立单一接口， 不要建立臃肿庞大的接口。 再通俗一点讲： 接口尽量细化， 同时接口中的方法尽量少。
与单一职责原则的区别：接口隔离原则与单一职责的审视角度是不相同的， 单一职责要求的是类和接口职责单一， 注重的是职责， 这是业务逻辑上的划分， 而接口隔离原则要求接口的方法尽量少。 例如一个接口的职责可能包含10个方法， 这10个方法都放在一个口
中， 并且提供给多个模块访问， 各个模块按照规定的权限来访问在系统外通过文档约束“不使用的方法不要访问”， 按照单一职责原则是允许的， 按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”。 专门的接口指什么？ 就是指提供给每个模的都应块该是单一接口， 提供给几个模块就应该有几个接口， 而不是建立一个庞大的臃肿的接口， 容纳所有的客户端访问。
接口隔离原则是对接口进行规范约束， 其包含以下4层含义：
● 接口要尽量小（根据接口隔离原则拆分接口时， 首先必须满足单一职责原则）
● 接口要高内聚（高内聚就是提高接口、 类、 模块的处理能力， 减少对外的交互。具体到接口隔离原则就是， 要求在接口中尽量少公布public方法， 接口是对外的承诺， 承诺越少对系统的开发越有利， 变更的风险也就越少， 同时也有利于降低成本）
● 定制服务（定制服务就是单独为一个个体提供优良的服务。 ）
● 接口设计是有限度的（接口的设计粒度越小， 系统越灵活， 这是不争的事实。 但是， 灵活的同时也带来了结构的复杂化， 开发难度增加， 可维护性降低， 这不是一个项目或产品所期望看到的， 所以接口设计一定要注意适度。）
五、迪米特法则（ Law of Demeter， LoD）
定义：一个对象应该对其他对象有最少的了解。
迪米特法则对类的低耦合提出了明确的要求， 其包含以下4层含义：
1. 只和朋友交流（朋友类的定义是这样的： 出现在成员变量、 方法的输入输出参数中的类称为成员朋友类， 而出现在方法体内部的类不属于朋友类；类与类之间的关系是建立在类间的， 而不是方法间， 因此一个方法尽量不引入一个类中不存在的对象）
2. 朋友间也是有距离的（一个类公开的public属性或方法越多， 修改时涉及的面也就越大， 变更引起的风险扩散也就越大。因此， 为了保持朋友类间的距离， 在设计时需要反复衡量： 是否还可以再减少public方法和属性， 是否可以修改为private、 package-private（ 包类型， 在类、 方法、 变量前不加访问权限， 则默认为包类型） 、 protected等访问权限， 是否可以加上final关键字等）
3. 是自己的就是自己的（在实际应用中经常会出现这样一个方法： 放在本类中也可以， 放在其他类中也没有错，那怎么去衡量呢？ 你可以坚持这样一个原则： 如果一个方法放在本类中， 既不增加类间关系， 也对本类不产生负面影响， 那就放置在本类中。）
4. 谨慎使用Serializable
六、开闭原则
定义： 一个软件实体如类、 模块和函数应该对扩展开放， 对修改关闭。
理解：一个软件实体应该通过扩展来实现变化， 而不是通过修改已有的代码来实现变化,它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。开闭原则是最基础的一个原则， 前五章节介绍的原则都是开闭原则的具体形态，也就是说前五个原则就是指导设计的工具和方法， 而开闭原则才是其精神领袖。
优点：
1.开闭原则可以方便测试人员测试。 （测试人员只要添加新的测试方法，测试扩展的类即可。而不用修改测试方法，重复测试已有代码。）
2.开闭原则可以提高复用性。（在面向对象的设计中， 所有的逻辑都是从原子逻辑组合而来的， 而不是在一个类中独立实现一个业务逻辑。 只有这样代码才可以复用， 粒度越小， 被复用的可能性就越大。 那为什么要复用呢？ 减少代码量， 避免相同的逻辑分散在多个角落， 避免日后的维护人员为了修改一个微小的缺陷或增加新功能而要在整个项目中到处查找相关的代码， 然后发出对开发人员“极度失望”的感慨。 那怎么才能提高复用率呢？ 缩小逻辑粒度， 直到一个逻辑不可再拆分为止。）
3.开闭原则可以提高可维护性。（一款软件投产后， 维护人员的工作不仅仅是对数据进行维护， 还可能要对程序进行扩展， 维护人员最乐意做的事情就是扩展一个类， 而不是修改一个类， 甭管原有的代码写得多么优秀还是多么糟糕， 让维护人员读懂原有的代码， 然后再修改， 是一件很痛苦的事情， 不要让他在原有的代码海洋里游弋完毕后再修改， 那是对维护人员的一种折磨和摧残。）
4.面向对象开发的要求。（万物皆对象， 我们需要把所有的事物都抽象成对象， 然后针对对象进行操作， 但是万物皆运动， 有运动就有变化， 有变化就要有策略去应对， 怎么快速应对呢？ 这就需要在设计之初考虑到所有可能变化的因素， 然后留下接口， 等待“能”转变为“现实”。）
使用规则：
1. 抽象约束。（通过接口或抽象类可以约束一组可能变化的行为， 并且能够实现对扩展开放， 其包含三层含义： 第一， 通过接口或抽象类约束扩展， 对扩展进行边界限定， 不允许出现在接口或抽象类中不存在的public方法； 第二， 参数类型、 引用对象尽量使用接口或者抽象类， 而不是实现类； 第三， 抽象层尽量保持稳定， 一旦确定即不允许修改。 接口是与其他模块交流的契约， 修改契约就等于让其他模块修改。 ）
2. 元数据（ metadata） 控制模块行为。（尽量使用元数据来控制程序的行为， 减少重复开发。 什么是元数据？ 用来描述环境和数据的数据， 通俗地说就是配置参数， 参数可以从文件中获得， 也可以从数据库中获得）
3. 封装变化。（对变化的封装包含两层含义： 第一， 将相同的变化封装到一个接口或抽象类中； 第二，将不同的变化封装到不同的接口或抽象类中， 不应该有两个不同的变化出现在同一个接口或抽象类中。）