很久以前看设计模式的时候，也没有看的太透彻，一直到现在，还是云里雾里，而且杂七杂八的知识早就忘得差不多了。
最近买了一本最经典的最基础的设计模式的书--《大话设计模式》，就此趁这机会在重学一遍，好好理一理思路。
六大原则
1、单一职责原则
字面理解，是要保持功能的单一，每个类或方法要尽量把实现的功能拆分出来，这样能保证低耦合，还能减少代码的重复量。
比如，从学生表中获取成绩大于90的学生，修改等级为A，如果放在一个方法里实现，那获取成绩大于90分的学生的功能就要重新写一个方法。
最好的办法是，将查询和修改写成两个方法，避免重用。这在mvc三层设计里就是经常使用的。
2、里氏替换原则
任何基类可以出现的地方，子类一定可以出现。
-->里氏替换原则规范（请参照：http://blog.csdn.net/hfreeman2008/article/details/52344343）
-->1）子类必须完全实现父类的方法
-->2）子类可以有自己独有的方法和属性
-->3）覆盖或实现父类的方法时输入参数可以被放大
-->4）覆盖或实现父类的方法时输出结果可以被缩小
3、依赖倒转原则
抽象不应该依赖细节，细节应该依赖于抽象。高层模块不应该依赖于低层模块，两者都应该依赖于抽象。
如果是高层依赖于低层，在低层模块需要更改时也需要更改高层模块，会导致模块的复用性降低而且大大提高了开发的成本。所以用依赖倒转，即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。
4、接口隔离原则
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
一般规则：
- 一个接口只服务于一个子模块或业务逻辑
- 接口尽量简洁
- 接口尽量不要更改
比如在简书上看到的一个例子：一个动物接口，一只狗，一只鸡，如果接口里定义了飞的方法，狗对象并不能使用。所以要再定义一个接口，将飞的方法放进去，由鸡来实现。
5、迪米特法则
一个软件实体应当尽可能少的与其他实体发生相互作用。就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
6、开闭原则
软件实体，包括类、函数、模块等，可以扩展，但不能修改。简单来说就是可以添加，不能改动。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即修改原有的代码对外部的使用是透明的。