1、开闭原则：Open Close Principle

是软件实体（类，模块，函数等）应该可以扩展，但是不可修改。

理解：只以基于原本的来扩展功能，但不能修改原本的代码。已经面对需求时，对程序的改动是通过增加新代码进行的，而不是更改现有代码。

2、依赖倒置原则：Dependence Inversion Principle（依赖接口编程）

A.高层模块不应该依赖低层模块，两个都应该依赖抽象。 B.抽象不应该依赖细节。细节应该依赖抽象。

理解：都针对定义的接口或抽象类来设计一个类，而不要依赖低层类来设计高层类。没理解，怎么实现，难道要抛弃低层模块？低层模块有有什么用？ 高层类依赖接口，低层类实现具体接口，再传给高层类使用。如更换低层类A，B的例子。

3、单一职责原则：Single Responsibility Principle

就一个类而言，应该仅有一个引起它变化的原因。

理解：写一个类，不要在其中设计太多的功能，当需要修改任一个功能时，就都需要修改这个类，这样比较麻烦。

4、里氏代换原则：Liskov Substitution Principle(LSP)（子类能替换父类）

子类型必须能够替换掉它们的父类型。

子类不能窄化接口 (里氏代换原则)
父类public  子类不能变protected  private

理解：这是在讲继承吗？比如企鹅不能继承于鸟类。 尽量不要重写父类方法。如加减法扩展功能时出错的例子。

5、迪米特原则（最少知道原则）：Demeter Principle（局部变量不调用）

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

理解：低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

6、接口隔离原则：Interface Segregation Principle（合理接口）

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

理解：不要在接口中设计一个类用不到的方法，尽量使接口细化，合理。接口也不能太细化，不然会增加接口的数量，使结构复杂。

设计模式六大原则