设计模式六大基础原则

1. 单一职责原则：（Single Responsibility Pinciple）

       一个类只负责一项职责，就负责一件事情。 当超过一项职责需要负责时，需要增加新的类来负责新的职责，而不是在类中增加新的代码。

      如果一个类承担的职责太多，就是高度地职责耦合，非常不利于扩展功能。这是非常脆弱的设计。容易发生修改一个地方而影响其他地方的情况。

遵循单一职责原则的优点：

• 降低类的复杂度
• 提高类的可读性，提高系统的可维护性
• 变更引起的风险降低

2.  里氏代换原则：子类可以扩展父类的功能，但不能改变父类原有的功能。

包含4层含义：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

不遵循里氏代换原则的后果是，写代码出错的机率会大大增加。

 

3.  依赖倒置原则：（Dependence Inversion）高层模块不应依赖低层模块，两个都应依赖于抽象。

        抽象不应该依赖于具体，具体应该依赖于抽象。

        依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

       依赖倒置原则的核心思想是面向接口编程， 而不是面向实现编程。

       在传统的开发架构中， controller-->service-->dao，就遵循了依赖倒置原则。 controller调用service的是API，service调用dao也是调用API。这样，API中的实现细节变化，不会影响API的调用者。

 

4.  迪米特原则：一个对象应该对其他对象保持最少的了解。

又叫最少知道原则。

通俗地说，就是一个类对自己依赖的类知道的越少越好。

也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。

迪米特法则还有一个更简单的定义：只与直接的朋友通信。

软件编程的总原则：低耦合，高内聚。

无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。

 

迪米特原则为了降低类与类之间的耦合。

 

5.  开闭原则： 对扩展开放，对修改关闭。

      一个软件实体，如类、模块和函数，对扩展开放，对修改关闭。

问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

 

      开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

 

      前面说的5项原则，恰恰是告诉我们用抽象构建框架，用实现扩展细节的注意事项而已：单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。