设计模式之——六个“设计原则”

前言：
最近在看设计模式，本文仅作为第一次学习设计模式的笔记。
仅作为学习参考。如有不足，希望各位大神能指出，我修改。

另外，所有的设计原则不是绝对的，要根据实际项目作出相应的妥协和调整才能达到最好的效果。
本文仅说明理论，具体的 需要“代码量的积累”和“写前的思考” 才能实现。

1. 单一职责原则：SRP

---

• 定义：应该有且仅有一个原因引起类的变更。
  即 “一个职责一个接口”。
  职责分明，结构清晰。

• 例如：用户的属性和用户的行为，需要分开写成两个接口。
  一个为用户的行为，一个为用户的属性。

• 原话：There should never be more than one reason for a class to change.

• 好处：

1. 降低类的复杂性
2. 可读性提高
3. 可维护性提高
4. 耦合性降低，变更引起的风险降低

2. 里氏替换原则：LSP

---

• 定义：只要父类能出现的地方子类就可以出现。
  其中包括4层：
  1.子类必须完全实现父类的方法
  2.子类可以有自己的个性
  3.覆盖或实现父类的方法时输入参数可以被放大
  4.覆写或实现父类的方法时输出结果可以被缩小

• 目的：增加程序的健壮性，添加子类，原有子类还可以继续运行。
  传递不同的子类完成不同的业务逻辑。

3. 依赖倒置原则：DIP

---

• 含义：
  1.高层模块不能依赖底层模块，模块都应该依赖其抽象
  2.抽象不应该依赖细节
  3.细节应该依赖抽象

• 实现：
  1.模块间依赖抽象，实现类之间不发生直接的依赖关系，其依赖关系通过接口或抽象类产生的
  2.接口或抽象类不依赖于实现类
  3.实现类依赖接口或抽象类

• 好处：减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

• 写法：如何模板依赖抽象？
  1.构造函数传递依赖对象
  2.Setter方法传递依赖对象
  3.接口声明依赖对象

• 最佳实践：
  1.每个类尽量都有抽象类或接口
  2.变量的表面类型尽量是接口或者是抽象类
  3.任何类都不应该从具体类派生
  4.尽量不要覆写基类的方法

4. 接口隔离原则：ISP

---

• 定义：客户端应仅依赖它需要的接口
  1.客户端不应该依赖它不需要的接口
  2.类间的依赖关系应该建立在最小的接口上

• 写法：
  1.接口要尽量小，职责单一，符合单一职责。
  2.通过业务逻辑压缩接口中的public方法（满身筋骨肉）

• 最佳实践：
  1.一个接口只服务于一个子模块（业务逻辑）
  2.通过业务逻辑压缩接口中的public方法（满身筋骨肉）
  3.已经污染了的接口，尽量去修改，风险大用适配器模式。

5. 迪米特法则：LoD

---

又叫“最小知识原则”

• 定义：一个对象应该对其他的对象有最少的了解。
  即 一个类应该对自己需要耦合或调用的类知道得最少。

• 四层含义：
  1.只与直接的朋友交流
  2.朋友间也是有距离的
  3.是自己的就是自己的
  4.谨慎使用Serializable

• 写法：编写时 反复斟酌：
  1.是否可以减少public的方法和属性
  2.是否可以加上private、protected、package-private
  3.是否可以加上final（防止被继承）

6. 开闭原则：OCP

---

原话：Software entities like classes,modules and functions should be open for extendsion but closed for modifications.
直译：软件实体应该对扩展开放，对修改关闭。
实体包括：逻辑模块、抽象和类、方法

• 定义：开闭原则是对前5个原则的总结，前五个原则对开闭原则的具体解释。

• 写法：
  1.抽象约束
  2.元数据（配置参数，来源于数据库、本地文件）控制子模块
  3.指定项目章程
  4.封装变化

• 好处：
  1.减少测试压力
  2.提高代码复用性
  3.提高项目可维护性
  4.面向对象开发的要求

开闭原则是项目的最终目标，不可能百分百做到，但朝着这个方向努力，可以改善架构，永远拥抱‘变化”，百变我不怕。

作为一名 95后 程序员小白，
第一次投稿还是有点紧张呢。。
如果哪里有异议，希望各位大神指出，我修改。
哈哈哈