设计模式的七大原则

设计模式的七大原则

• 单一职责原则

  • 比如本来设计的一个功能模块α可以完成功能A和功能B，此时α就不具备单一职责，而是具有A和B两个职责，如果要履行单一职责原则，就要把α拆分成模块A和模块B

• 接口隔离原则

  • 假设C1类实现I接口（包含你m1,m2,m3,m4,m5五个方法），C2调用C1类。如果C2只需要用到C1实现I的部分方法（比如只调用C2实现的m1,m2方法），C3调用C1，只调用C1的m4，m5方法，并不需要用到C1实现的全部方法。这样就没有产生接口隔离，因为会有用不到的m3,m4,m5方法。如果要履行接口隔离原则，那么就需要把I拆分成I1（包含m1,m2,m3）和I2（m4,m5），这样C2和C3调用C1的时候，就遵循了接口隔离原则。

• 依赖倒转原则

  • 意思其实就是，抽象的不要依赖具体的，比如抽象类不要继承普通类。越基本的接口，越要处在依赖关系的顶层。原因就是越抽象的东西，越稳定，越具体的越容易改变，依赖倒转原则就是为了实现程序的稳定性

• 里氏替换原则

  • 对于T1类型有其对象O1，T2类型有其对象O2。对于由O1实现的程序P，当P中所有的O1都替换成O2时，p的行为不变，那么O2就是O1的子类。
  • 意思就是O2不要重写O1的方法。
  • 如果O2必须要重写O1的方法，那么根据里氏替换原则，可以使O2和O1处于同一个级别，让两个对象去同时继承一个更加基本的对象或者接口。其实就是提取出更加抽象的东西。跟柏拉图的哲学体系一样的。

• 开闭原则

  • 对程序的开发者时发放的，但是对程序的使用者是关闭的。
  • 如果要增加程序的功能，可以在不修改原有代码的基础上，去添加一些新的代码，就是开闭原则。
  • 个人理解其实也就是抽象，为了增加新的功能，就去继承最抽象的，实现最具体的。

• 迪米特法则

  • 一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类，不管内部功能实现起来多么复杂，都只对外暴露一个public方法
  • 有这么一个说法：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系， 我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合 等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而 出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量 的形式出现在类的内部。
  • 迪米特法则的目的是为了降低代码之间的耦合。相比出现在成员变量，方法参数，方法返回值中的类，出现在局部变量中的类的耦合程度更深，所以要尽量去避免。

• 合成复用原则

  • 原则是尽量使用合成/聚合的方式，而不是使用继承
  • 如果用继承的方式，代码之间的耦合性会增强，其实就是一个类想用另一个类的方法，就通过调用的方式来用就行。比如A想用B的方法，如果采用继承的方式，那么方法名字也都继承了。如果A不想用B的方法了，换一个类继承时，方法的名字等等都可能会改变，不如通过调用的方式，想换就换。