设计模式-六大原则

设计模式的六大原则

• 单一职责原则（Single responsibility principle）：一个类的职责应该单一

1. 如果一个类职责过多，应该拆分

       （类如果职责单一，那导致类修改的原因也会唯一，不会因为多种原因都要去修改类）

• 开放-关闭原则（Open Close Principle）：也叫开闭原则，要求程序对扩展开放，对修改关闭

1. 在程序扩展新功能时，不修改原有代码，而是进行扩展，使程序的扩展性好，维护性好

• 里氏替换原则（Liskov Substitution Principle）：所有父类出现的地方，子类都能替换，并且结果不变

1. 子类可以实现父类的抽象方法，但子类不应该重写父类已实现的方法
2. 子类可以增加自己的独有方法
3. 子类的方法重载父类的方法时，方法的形参要比父类方法的形参更宽松
4. 子类的方法实现父类的抽象方法时，方法的返回值要比分类更严格

• 接口隔离原则（Interface Segregation Principle）：每个接口中都不存在子类用不到又必须实现的方法

1. 如果存在，需要拆分

• 依赖倒转原则（Dependence Inversion Principle）：应该面对接口编程，而不是面对细节编程

1. 高层模块不依赖底层，两个都应该依赖接口（一个模块引用了链接数据库的代码，高层依赖了底层，如果替换数据库时，需求修改高层代码，无法复用，如果依赖接口，则新增数据库链接实现类即可）
2. 抽象不应该依赖细节，细节应该依赖抽象

（以上原则英文首字母组成SOLID，又叫SOLID准则）

• 迪米特法则（又叫最少知道原则）（Law of Demeter）：如果两个二类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用

1. 一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类
2. 只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中

 

---

 

 

总结：原则应该根据实际情况来尽量满足，也不用一味纠结于是否满足原则。