设计模式——六大原则

首先介绍设计模式的六大原则，它们分别

• 单一职责原则
• 开放封闭原则
• 里氏替换原则
• 依赖倒置原则
• 迪米特原则
• 接口隔离原则

1. 单一职责原则

就一个类而言，应该仅有一个引起它变化的原因：

• 通俗地讲就是我们不要让一个类承担过多的职责。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到破坏
• 比如我们会看到一些开发者在Activity中写Bean文件、网络数据处理，如果有列表的话 Adapter 也写在 Activity 中。至于他们为什么这么做，除了好找也没什么理由了。
• 把其拆分到其他类岂不是更好找？如果 Activity 过于臃肿、行数过多，显然不是好事。如果我们要修改Bean文件、网络处理和Adapter都需要上这个Activity来修改，就会导致引起该Activity变化的原因太多，我们在版本维护时也会比较头疼。
• 这也就严重违背了定义：“就一个类而言，应该仅有一个引起它变化的原因。”单一职责的划分界限不是很清晰，很多时候需要靠个人经验来界定，因此它是一个饱受争议却又极其重要的原则。

2. 开放封闭原则

类、模块、函数等应该是可以拓展的，但是不可修改。开放封闭有两个含义

• 一个是对于拓展是开放的，另一个是对于修改是封闭的，对于开发来说，需求肯定是要变化的，但是有新需求，我们就要把类重新改一遍，这显然是令人头疼的。
• 所以我们设计程序时，面对需求的改变要尽可能地保证相对稳定，尽量通过扩展的方式来实现变化，而不是通过修改原有的代码来实现
• 假设我们要实现一个列表，一开始只有查询的功能，后来产品又要新增“添加”功能，过几天又要增加“删除”功能。大多数人的做法是写一个方法，然后通过传入不同的值控制方法来实现不同的功能。
• 但是如果又要新增功能，我们还得修改方法。用开发封闭原则解决就是增加一个抽象的功能类，让添加、删除和查询作为这个抽象功能类的子类。这样如果我们再新增功能，你就会发现自己无须修改原有的类，只需要添加一个功能类的子类实现功能类的方法就可以了。

3. 里氏替换原则

所有引用基类（父类）的地方必须能透明地使用其子类的对象。

• 里氏替换原则告诉我们，在软件中将一个基类对象替换成其子类对象，程序将不会产生任何错误和异常；反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。
• 里氏替换原则是实现开放封闭原则的重要方式之一。由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。在使用里氏替换原则时需要注意以下几个问题。
  • 子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏替换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义。如果一个方法只存在子类中，在父类中提供相应的声明，则无法在以父类定义的对象中使用该方法。
  • 在运用里氏替换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法。运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码
  • 在Java语言中，在编译阶段，Java编译器会检查一个程序是否符合里氏替换原则。这是一个与实现无关的、纯语法意义上的检查，但Java编译器的检查是有局限性的。

4. 依赖倒置原则

高层模块不应该依赖低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象

• 在Java中，抽象指接口或者抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或者继承抽象类而产生的就是细节，也就是可以加上一个关键字new产生的对象。
• 高层模块就是调用端，低层模块就是具体实现类。依赖倒置原则在Java中的表现就是，模块间的依赖通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是通过接口或者抽象类产生的。如果类与类直接依赖细节，那么就会直接耦合。如此一来当修改时，就会同时修改依赖者代码，这样限制了可扩展性。

5. 迪米特原则

一个软件实体应当尽可能少地与其他实体发生相互作用

• 这也被称为最少知识原则。如果一个系统符合迪米特原则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块。
• 迪米特原则要求我们在设计系统时，应该尽量减少对象之间的交互。如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用。如果其中的一个对象需要调用另一个对象的某一个方法，则可以通过第三者转发这个调用。
• 简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。在将迪米特原则运用到系统设计中时，要注意下面几点：
  • 在类的划分上，应当尽量创建松耦合的类。类之间的耦合度越低，就越有利于复用。一个处在松耦合中的类一旦被修改，则不会对关联的类造成太大波及。
  • 在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限。
  • 在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

6. 接口隔离原则

一个类对另一个类的依赖应该建立在最小的接口上

• 建立单一接口，不要建立庞大臃肿的接口；尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图建立一个很庞大的接口供所有依赖它的类调用。采用接口隔离原则对接口进行约束时，要注意以下几点：
  • 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计的灵活性；但是如果过小，则会造成接口数量过多，使设计复杂化。所以，一定要适度。
  • 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
  • 提高内聚，减少对外交互。接口方法尽量少用public修饰。接口是对外的承诺，承诺越少对系统的开发越有利，变更风险也会越少。