“walk beside you ”
前言
最近在看设计模式之禅所以记录下所看到的~
正文
设计模式有6大设计原则：单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则
单一职责原则
单一职责原则（Single Responsibility Principle 简称 SRP） 定义为：应该有且仅有一个原因引起类的变更。 也就是一个类或接口值负责一个职责。
单一职责同时适用于方法上面，表示一个方法只负责一个功能，比如：修改姓名、修改密码、退出登录等等。
单一职责原则的中心思想就是，一个类、接口、方法 都应该只为一个功能、方法、操作而服务。在程序设计的时候，功能方法应该尽可能的拆分开来， 所以当一个功能发起改变的时候，不会引起大规模的修改。
单一职责原则优点：
- 类的复杂性降低，实现什么职责都有明确的定义
- 可读性提高
- 可维护性提高
- 变更引起的风险降低
里氏替换原则
里氏代换原则(Liskov Substitution Principle, LSP) 定义为：所有引用基类的地方必须能透明地使用其子类的对象。 通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
里氏替换原则为良好的继承定义了一个规范，一句简单的定义包含了4层含义。
- 子类必须完全实现父类的方法
- 子类可以有自己的个性
- 覆盖或实现父类的方法时输入参数可以被放大
- 覆盖或实现父类方法时输出结果可以被缩小
依赖倒置原则
依赖倒置原则（Dependence Inversion Principle,DIP） 定义为：
- 高层模块不应该依赖底层模块，两者都应该依赖抽象
- 抽象不应该依赖细节
- 细节应该依赖抽象（面向接口编程）
依赖倒置原则在Java中的表现为：
- 模块间的依赖通过抽象发生，实现类之间不能发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的
- 接口或抽象类不依赖于实现类
- 实现类依赖接口或抽象类
依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：
- 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
- 变量的表面类型尽量是接口或者是抽象类
- 任何类都不应该从具体类派生
- 尽量不要覆写基类的方法
- 结合里氏替换原则使用
接口隔离原则
接口隔离原则(Interface Segregation Principle, ISP)：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。
与单一原则不同的所审视的角度不同：
- 单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分
- 接口隔离原则要求接口的方法尽量少
接口隔离原则是对接口进行规范约束，其包含以下4层含义：
- 接口要尽量小
- 接口要高内聚
- 定制服务
- 接口设计是有限度的
接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。 但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个规则来衡量：
- 一个接口只服务于一个子模块或业务逻辑
- 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法
- 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理
- 了解环境，拒绝盲从
迪米特法则
迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP）：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义：
- 只和朋友交流
每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等
- 朋友间也是有距离的
人和人之间是有距离的，太远关系逐渐疏远，最终形同陌路；太近就相互刺伤。对朋友关系描述最贴切的故事就是：两只刺猬取暖，太远取不到暖，太近刺伤了对方，必须保持一个既能取暖又不刺伤对方的距离。迪米特法则就是对这个距离进行描述，即使是朋友类之间也不能无话不说，无所不知。
- 是自己的就是自己的
如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
- 谨慎使用Serializable
开闭原则
开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。