设计模式，老生常谈，今天总结一下设计模式的六大原则，希望能结合过往的编程经验，对他们有一个更加深刻的认识体会。
1、单一职责原则 （Single Responsibility Principle）：一个类只负责一项职责，尽量做到类的只有一个行为原因引起变化；
a、业务对象（BO business object）、业务逻辑（BL business logic）拆分；
分析：
我们在设计程序结构的时候，如果不注重这个原则，一个类、接口 里面充满了各种各样的行为，就会导致程序的冗余，耦合度大增，极不利于拓展维护。
2、里氏替换原则（LSP liskov substitution principle）：子类可以扩展父类的功能，但不能改变原有父类的功能；
（目的：增强程序的健壮性）实际项目中，每个子类对应不同的业务含义，使父类作为参数，传递不同的子类完成不同的业务逻辑。
分析：
- 子类必须实现父类的抽象方法，但不得重写（覆盖）父类的非抽象（已实现）方法。
- 子类中可以增加自己特有的方法。
- 当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
- 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
3、依赖倒置原则（dependence inversion principle）：面向接口编程；（通过接口作为参数实现应用场景）
抽象就是接口或者抽象类，细节就是实现类，思考一下：我们的代码中是否真的注意了要去“抽象”，即定义抽象类和接口。
分析：
上层模块不应该依赖下层模块，两者应依赖其抽象；
抽象不应该依赖细节，细节应该依赖抽象；
接口负责定义public属性和方法，并且申明与其他对象依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑
4、接口隔离（interface segregation principle）：建立单一接口；（扩展为类也是一种接口，一切皆接口）
定义：
a.客户端不应该依赖它不需要的接口；
b.类之间依赖关系应该建立在最小的接口上；
分析：
接口的设计粒度越小，系统越灵活，但是灵活的同时结构复杂性提高，开发难度也会变大，维护性降低
5.迪米特原则（law of demeter LOD）：最少知道原则，尽量降低类与类之间的耦合；
一个对象应该对其他对象有最少的了解
分析：
这个原则，其实很好理解，我们在一个类中要尽量减少对别的类或者对象的引用，这在我们实际的编程过程中，要尤为注意，尽量降低类与类之间的耦合，使得我们的程序易于维护。
6、开闭原则（open closed principle）：用抽象构建架构，用实现扩展原则；（总纲）
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
软件对象（类、模块、方法等）应该对于扩展是开放的，对修改是关闭的。
分析：
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
总结：
单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。