本文主内容主要是列出各项原则的定义与本人对六大原则的感悟。写出来的目是想与大家分享与讨论。正如有句话叫做一千个读者眼中有一千个哈姆雷特，如果大家对这六项原则的理解跟我有所不同，欢迎留言，大家共同探讨。
1 单一职责原则
定义：就一个类而言，应该仅有一个引起它变化的原因。应该只有一个职责。
类和方法的职责要单一，不要把不同的业务逻辑放在同一个类里面(或同一个方法里面)。
2 迪米特法则(最少知道原则)：
定义：一个对象应该对其他对象保持最少的了解。
降低耦合，一个类尽可能的减少依赖。依赖越少越好。
3 里氏替换原则
定义：派生类(子类)对象可以在程式中代替其基类(超类)对象。
不要破坏类的基层体系。扩展父类的时候，不要去覆盖父类的非抽象方法；尽量去拓展，而不是去覆盖；
4 依赖倒置，面向接口编程；尽可能的通过接口去依赖
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
面向接口编程；尽可能的通过接口去依赖；
5 接口隔离原则：
定义：客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。
接口尽可能的精简，单一。尽量细化接口，暴露的东西越少越好。(接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。)
6 开闭原则：
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
开闭原则是前5个原则的综合得分体现，前五个原则遵守得好，那么设计出来的软件自然是符合开闭原则的，如果前面5项原则遵守得不好，说明开闭原则遵守的不好。
总结：设计模式实际上表达的是这样子的一种思想：用抽象构建架构，用实现拓展细节。
因为抽象灵活性高，适用性广，因此用抽象来构建架构可以保持软件的稳定(前提是要抽象得合理)。而软件中的细节，我们用从抽象类中派生出来的实现类来进行拓展，当软件需求发生改变时，我们只需要根据需求重新派生新的实现类来进行拓展就行。
单一职责告诉我们类的职责要单一。迪米特法则告诉我们要降低耦合。里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们接口在的设计的时候要精简，单一；而开闭原则是像是总纲，他告诉我们要对扩展开放，对修改关闭。
