《设计模式之禅》经过一个假期的阅读也有一点小收获，充实了自己的假期吧！以下是自己的一点点见解，理解尚浅谨以此记录自己的学习经历。
第一部分 六项基本原则
单一职能原则：
每一个类实现的功能和作用要单一，比如实体类实现的是单纯的属性和get,set方法,是为了能生成一个纯净的类。实现逻辑操作的要重新生成一个类，不要在实体类中给出复杂业务逻辑的操作。调用到业务逻辑的服务操作也要重新生成一个类，边界尽量清晰。单一职责原则最难划分的就是职责。
单一职责原则有什么好处：
● 类的复杂性降低，实现什么职责都有清晰明确的定义；
● 可读性提高，复杂性降低，那当然可读性提高了；
● 可维护性提高，可读性提高，那当然更容易维护了；
● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修
改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大
的帮助。
里氏替换原则：
子类可以继承父类的私有方法以外的所有方法和非私有的属性，重写可以覆盖掉父类中同名同参数的方法。
子类必须完全实现父类的方法。
子类可以有自己独立的属性和方法。
覆盖或实现父类的方法时输入参数可能会被放大。（如果子类给的参数范围大于父类，不会被执行到，要求子类给参数类型必须等于父类）。
覆盖或者实现父类的方法时输出可以被缩小范围。（父类的返回参数类型必须大于子类）
依赖倒置的原则
三层含义
● 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过
接口或抽象类产生的；
● 接口或抽象类不依赖于实现类；
● 实现类依赖接口或抽象类。依赖的三种写法
1.构造函数传递依赖对象
2.Setter方法传递依赖对象
3.接口声明依赖对象
需要遵循的几个规则
● 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
● 变量的表面类型尽量是接口或者是抽象类
● 任何类都不应该从具体类派生
● 尽量不要覆写基类的方法
接口隔离
接口实现的作用越简单越好，最好是只针对某一项相同对象的。
● 一个接口只服务于一个子模块或业务逻辑；
● 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨
肉”，而不是“肥嘟嘟”的一大堆方法；
● 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化
处理；
● 了解环境，拒绝盲从。
迪米特法则：
类之间的调用，最好不要知道被调用者中其他信息，只要知道对应的接口即可。具体如何实现不需要知道，或者越少越好。
开闭原则：
使用extends(继承)的方法实现原有的类的方法以及扩展其中的应用，应用去系统升级，替换实现类即可，不需要太多变动。