设计模式6大原则简介

1.单一职责原则（SRP）

有且仅有一个原因引起类的变更。

说到底还是如何抽象的问题，如何从业务中抽象出不同且关联尽可能小的模块。

举个例子吧（引用设计模式之禅）

打电话过程：拨号->聊天->挂断

为了尽可能让单一职责原则满足，我们将这个过程分为连接和数据传输。把职责的界限划分清楚点，但是这个界面有可能因而而已了，所以这个也是比较有争议的原则。

• 类的的复杂性降低，实现什么样的职责有清晰明确的定义
• 可读性提高，复杂性降低
• 可维护性提高，可读性提高
• 变更引起的风险降低，随着业务不断发展，变更的可能性很大，所以这个原则大有用处。

解决的是职责问题。

---

单一职责原则提出了一个编写程序的标准，用"职责“或者”或者“变化原因”来衡量接口或者设计的是否优良，但是职责“或者”和“变化原因”又太主观了，因项目而异，因环境而异，但是也不要过度的分清职业，这样有可能导致开发成本和维护成本过高，人是活的，技术是死的

---

2.里氏替换原则（LSP）

• 子类必须完全实现父类的方法
  在实际的编码过程中，我们定义了接口或者抽象类，可以直接引用他们，实际就是里氏替换原则

---

在类中调用其他类时必须使用父类或者接口，如果不能使用父类或者接口，说明类的设计违背了（LSP）

---

• 子类可以有自己的个性
  里氏替换原则不能反过来用，子类出现地方，父类不一定能胜任。什么意思？允许子类定义自己的属性或者方法

• 覆盖或者实现父类的方法时输入参数可以被放大
  什么意思呢？若是父类中的参数为具体实现类，子类中的参数可以使用它的抽象类，如父类的参数使用HashMap，子类可以使用Map。

• 覆盖或者实现父类的方法时输出结果可以被缩小

解决的是系统升级时，类的替换问题。

3.依赖倒置原则（DIP）

三层含义：

• 高层模块不依赖底层模块，两者都应该依赖其抽象。
• 抽象不应该依赖细节。
• 细节应该依赖抽象。

在Java中的表现为：

• 模块件的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过抽象或者接口发生。
• 接口或者抽象不依赖于实现类
• 实现类依赖接口或者抽象
  总结为：面向接口编程

解决的是依赖的问题。

4.接口依赖原则

• 接口:

• 类接口
  Java中使用的接口interface。

• 实例接口
  Java中的类也是一种接口

• 隔离：

• 客户端不应该依赖它不需要的接口

• 类之间依赖应该建立在最小的接口上。

5.开闭原则OCR

---

开闭原则是对扩展开放，对修改关闭，并不意味着不做任何修改

---

• 1.抽象约束
  包括三层含义，
  一、通过接口或者抽象类约束扩展，对扩展进行边界限定。
  二、参数类型、引用类型尽可能使用抽象类或者接口，而非实现类。
  三、抽象类尽可能保持稳定，一但定义好不允许修改。

• 2.元数据控制模块行为
  什么是元数据呢？描述环境和数据的数据。将元数据通过配置的方式存在。

• 3.封装变化

• 将相同的变化封装到一个接口或者抽象类。

• 将不同的变化抽象到不同的接口或者抽象类。

6.迪米特原则

又称最少知识原则，若是两个类产生依赖，则只需要知道我必须要的信息，其他的一概不管