设计模式的六大原则

1、开闭原则（Open Close Principle）

    开闭原则的意思是：对扩展开放，对修改关闭。

    也就是在程序需要进行拓展的时候，不去修改原有的代码，可以热插拔，使程序的扩展性好，易于维护和升级。想要达到这样的效果，需要使用接口和抽象类。

    如果一个系统在扩展时只涉及到修改配置文件，而原有的代码没有做任何修改，该系统即可认为是一个符合开闭原则的系统。

2、里氏代换原则（Liskov Substitution Principle）

     里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。

    也就是说将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，而反过来则不成立，使用的是一个子类对象，那么它不一定能够使用基类对象。例如一个方法接收父类对象，那么这个方法也可以接收子类对象。由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

    里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

    在使用里氏代换原则时需要注意如下几个问题：

      (1)子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。

      (2) 尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。

    (3)Java语言中，在编译阶段，Java编译器会检查一个程序是否符合里氏代换原则，这是一个与实现无关的、纯语法意义上的检查，但Java编译器的检查是有局限的。

3、依赖倒转原则（Dependence Inversion Principle）

      抽象不应该依赖于细节，细节应当依赖于抽象， 也就是针对接口编程，依赖于抽象而不依赖于具体。

     这个原则是开闭原则的基础。

     在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。模块间通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是通过接口或者抽象类产生的。如果类与类直接依赖细节，那么就会直接耦合，那么当修改时，就会同时修改依赖者代码，这样限制了可扩展性。

    在实现依赖倒转原则时，我们需要针对抽象层编程，而将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注入，设值注入（Setter注入）和接口注入。构造注入是指通过构造函数来传入具体类的对象，设值注入是指通过Setter方法来传入具体类的对象，而接口注入是指通过在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。

4、接口隔离原则（Interface Segregation Principle）

    这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。强调降低依赖，降低耦合。

5、迪米特法则，又称最少知道原则（Demeter Principle）

    一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

    应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。在类的设计上，只要有可能，一个类型应当设计成不变类。在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

6、单一职责原则，又称合成复用原则（Composite Reuse Principle）

    尽量使用合成/聚合的方式，而不是使用继承。通俗讲就是我们不要让一个类承担过多的职责。

    一个类承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。