单一职责原则

<aside> 💡

单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因

</aside>

一个类职责过多产生的问题

• 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力
• 这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏

如果能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责

开放-封闭原则

<aside> 💡

开放-封闭原则：即软件实体（类、模块、函数等）应该对扩展是开放的，对更改是封闭的

</aside>

无论模块多么“封闭”，都会存在一些无法对之封闭的变化

• 设计人员必须对于他设计的模块应该对哪种变化封闭做出选择
• 必须先猜测出最有可能发生变化的种类，然后构造抽象来隔离那些变化
  • 当变化发生时，立刻创建抽象来隔离一行发生的同类变化

面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码

依赖倒置原则

<aside> 💡

依赖倒置原则：

1. 高层模块不应该依赖低层模块，两者都应该依赖抽象（即接口或抽象类）
2. 抽象不应该依赖细节，细节应该依赖抽象 </aside>

高层模块不应该依赖于低层模块，二者都应该依赖于抽象：

• 在传统设计中，高层模块通常会依赖低层模块的具体实现
• 依赖倒转原则要求将这种依赖“倒转”过来，高层模块和低层模块都依赖于一个共同的抽象（接口或抽象类），从而减少模块之间的耦合。
  • 只要接口是稳定的，那么对任何一个模块进行更改都不用担心其他模块受到影响

抽象不应该依赖于细节，细节应该依赖于抽象：

• 在设计时，抽象层不应该了解具体的实现细节，而具体实现应该依赖于抽象层
• 这样做的目的是增强系统的灵活性和可扩展性，使得具体的实现细节可以独立于抽象变化而变化
  • 无论高层模块还是低层模块都可以很容易地被复用（里氏代换原则）