设计模式必知的六大原则

单一职责原则 – SRP

There should never be more than one reason for a class to change.

一个类的变化永远不应该有一个以上的原因 应该有且仅有一个原因引起类的变更

• 类的复杂性降低，实现什么职责都有清晰明确的定义
• 可读性提高，复杂性降低
• 可维护性提高

里氏替换原则 – LSP

继承的优点：

• 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性
• 提高代码的重用性
• 提高代码的课扩展性
• 可扩展性提高
• 提高产品或项目的开放性

继承的缺点：

• 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法
• 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界多了些约束
• 曾强了耦合性

只要父类能出现的地方子类就可以实现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必能适应。

里氏替换原则定义了一个规范：

子类必须完全实现父类的方法 注意： 在类中调阅其他类型时任务必须要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。 如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

依赖倒置原则

包含三层含义：

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
• 抽象不应该依赖细节；
• 细节应该依赖抽象。
• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
• 接口或抽象类不依赖于实现类；
• 实现类依赖接口或抽象类。
  依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合
• 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
  这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
• 变量的表面类型尽量是接口或者是抽象类
• 任何类都不应该从具体类派生
• 尽量不要覆写基类的方法
• 结合里氏替换原则使用

接口隔离原则

• 实例接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实
  例，它是对一个类型的事物的描述，这是一种接口。
• 类接口（Class Interface），Java中经常使用的interface关键字定义的接口。
• Clients should not be forced to depend upon interfaces that they don’t use.（客户端不应该依
  赖它不需要的接口。）
• The dependency of one class to another one should depend on the smallest possible interface.
  （类间的依赖关系应该建立在最小的接口上。）
• 一个接口只服务于一个子模块或业务逻辑；
• 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨
  肉”，而不是“肥嘟嘟”的一大堆方法；
• 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化
  处理；
• 了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的
  你就照抄。

迪米特原则

      迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least KnowledgePrinciple，LKP），虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

      迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。

开闭原则

核心思想：软件实体应该对扩展开放，对修改关闭

软件实体包括以下几个部分：

• 项目或软件产品中按照一定的逻辑规则划分的模块。
• 抽象和类。
• 方法。

开闭原则的重要性：

• 开闭原则对测试的影响
• 开闭原则可以提高复用性
• 开闭原则可以提高可维护性
• 面向对象开发的要求

如何使用开闭原则：

• 抽象约束
  • 通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；
  • 参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；
  • 抽象层尽量保持稳定，一旦确定即不允许修改
• 元数据（metadata）控制模块行为
• 制定项目章程
• 封装变化
  a. 第一，将相同的变化封装到一个接口或抽象类中；
  b. 第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。