软件设计原则

经典 7 大原则

1. 单一职责原则

单一职责原则是指：对类来说的，即一个类应该只负责一项职责。

换句话说就是让一个类只负责一件事，当这个类需要做过多事情的时候，就需要分解这个类。

如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱这个类完成其它职责的能力。

如类 A 负责两个不同职责：职责 1 ，职责 2 。

当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1 ， A2

单一职责原则注意事项和细节

1. 降低类的复杂度，一个类只负责一项职责。
2. 提高类的可读性，可维护性
3. 降低变更引起的风险
4. 通常情况下， 我们应当遵守单一职责原则

   • 只有逻辑足够简单，才可以在代码级违反单一职责原则
   • 只有类中函数数量足够少，可以在函数级别保持单一职责原则[

](https://blog.csdn.net/qq_44065088/article/details/108097839)

2. 开闭原则

对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，简言之，是为了使程序的扩展性好，易于维护和升级。

该原则要求在添加新功能时不需要修改代码，符合开闭原则最典型的设计模式是装饰者模式，它可以动态地将责任附加到对象上，而不用去修改类的代码。

想要达到这样的效果，我们需要灵活使用接口和抽象类。

3. 里氏代换原则

任何基类可以出现的地方，子类一定可以出现。

子类对象必须能够替换掉所有父类对象。

通俗理解：子类可以扩展父类的功能，但不能改变父类原有的功能。
换句话说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。

继承是一种 IS-A 关系，子类需要能够当成父类来使用，并且需要比父类更特殊。 如果不满足这个原则，那么各个子类的行为上就会有很大差异，增加继承体系的复杂度。

4. 依赖倒转原则

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

高层模块包含一个应用程序中重要的策略选择和业务模块，如果高层模块依赖于低层模块，那么低层模块的改动就会直接影响到高层模块，从而迫使高层模块也需要改动。

简单的说：要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

依赖于抽象意味着：

• 任何变量都不应该持有一个指向具体类的指针或者引用；
• 任何类都不应该从具体类派生；
• 任何方法都不应该覆写它的任何基类中的已经实现的方法。

5. 接口隔离原则

客户端不应该被迫依赖于它不使用的方法；一个类对另一个类的依赖应该建立在最小的接口上。

不应该强迫客户依赖于它们不用的方法，因此使用多个专门的接口比使用单一的总接口要好。

6. 迪米特法则

迪米特法则又叫最少知识原则。
只和你的直接朋友交谈，不跟 “ 陌生人 “ 说话（Talk only to your immediate friends and not to strangers）

其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

“ 朋友 “ 是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

7. 合成复用原则

合成复用原则是指：尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

通常类的复用分为继承复用和合成复用两种

继承复用虽然有简单和易实现的优点，但它也存在以下缺点：

1. 继承复用破坏了类的封装性。

   继承会将父类的实现细节暴露给子类，父类对子类是透明的，故而这种复用又称为 “ 白箱 “ 复用。

2. 子类与父类的耦合度高。

   父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。

3. 它限制了复用的灵活性。

   从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已
有对象的功能，它有以下优点：

1. 它维持了类的封装性。

   因为成分对象的内部细节是新对象看不见的，所以这种复用又称为 “ 黑箱 “ 复用。

2. 对象间的耦合度低。

   可以在类的成员位置声明抽象。

3. 复用的灵活性高。

   这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

其他常见原则

8. 共同封闭原则

一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。

最稳定的包应该是最抽象的包，不稳定的包应该是具体的包，即包的抽象程度跟它的稳定性成正比。

9. 稳定抽象原则

最稳定的包应该是最抽象的包，不稳定的包应该是具体的包，即包的抽象程度跟它的稳定性成正比。

9. 稳定依赖原则

包之间的依赖关系都应该是稳定方向依赖的，包要依赖的包要比自己更具有稳定性。