常见设计原则

Posted 2021-09-07 鱼翔空

设计模式是软件设计中常见问题的典型解决方案。它们就像能根据需求进行调整的预制蓝图， 可用于解决代码中反复出现的设计问题。

• 设计模式相对比较软性，是对解决某类场景问题的高层描述；

• 根据使用人的不同应用的也不同

• 只是一种思想，没有好坏之分，只有更适合；

• 我们应该关注要达到什么样的目的，怎么更加灵活的做到；

• 软件中唯一不变的是变化，设计模式让我们想各种方法屏蔽这种变化；

设计模式包含：

• 意图：简单描述问题和解决方案

• 动机：进一步解释问题并说明模式会如何提供解决方案；

• 结构：如何将软件结构组装起来并形成关系

设计原则：

SOLID原则 solid->稳定的

• S Single Responsibility Principle: 单一职责原则

• O open closed Principle: 开闭原则

• L Liskov Substritution Principle: 里氏替换原则

• I Interface Segegation Principle: 接口隔离原则

• D Dependence inversion Principle: 依赖倒置原则

内聚：从功能相关来谈，主张高内聚，把功能高度相似的代码内聚到一起，方便统一维护；耦合：从功能无关来谈，主张低耦合。不要把明显无关的功能随意结合，以降低耦合性；在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或很少导致依赖类的代码改动；

单一职责原则 SRP（Single Responsibility Principle）

定义：一个类或者模块只负责完成一个功能。特点：

• 模块可以看作是类的抽象或者是聚合；

• 单一，只是在特定的场景下单一， 比如一个类单一，一个模块单一

• 单一尽可能设计的粒度小、功能单一

• 比如下单功能，可能涉及到下单，查询用户，查询地址，优惠券使用，每一点都是单一功能，不要一写写一坨；

实现目的：从自身角度考虑代码的高内聚、低耦合、提高代码的复用性、可读性、可维护性；

开闭原则 OCP （Open Closed Principle）

定义：对扩展开放，对修改关闭

特点：

• 添加新功能，在已有的代码基础上扩展代码（新增类、方法等），而非修改已有的代码

• 开闭原则并不是完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发；

• 同样的代码改动，在粗代码力度下，可以被被认定为修改，在细代码力度下，被认为是扩展；

• 提高代码扩展性的方法：多态、依赖注入、面向接口编程、适配、装饰、策略、模板、责任链、状态等

• 对扩展开放是未了应对软件的变化，对修改关闭是未了保证系统的稳定性，最后是未了让系统具备可扩展性（弹性）；

• 也不要一味的遵循开闭，导致代码的复杂度过度的增加；

• 开闭也减少了测试的复杂度；

实现目的：基于自身考虑代码的结构，解决代码的扩展性的问题

里氏替换原则 LSP Liskov Substitution Principle

定义：值对象能够替换程序中的父对象出现的任何地方，并保证原来程序的逻辑以及正确性不变。也就是说在子类实现父类的时候，要遵守父类的行为约定。子类可以改变内部的实现逻辑，但不能改变函数原有的行为约定（比如子类冒出一个父类未知的异常，或者状态码）

特点：

• 子类能替换父类出现的任何地方；

• 子类必须严格遵守父类的行为约定（新增的异常、状态码，只有在子类逻辑中触发，不能在父类中触发），以保证原有程序的正确性；

• 里氏替换原则和多态有点类似

• 多态是面向对象的一大特性，也是面向对象的一种语法；

• 多态是一种代码实现的思路

• 里氏替换原则是一种设计原则，用来指导继承关系中子类应该如何设计；

实现目的：改进已有实现（对父类的代码进行增强）、指导程序开发（类的组织关系）、改进抽象设计；

接口隔离原则 ISP Interface Segregation Principle

定义：调用者（使用者）不应该被强迫依赖它不需要的接口。三种场景：

• 一组API接口集合：比如dubbo提供的Api，一个接口内可能有好几个方法，我们只需要使用其中一个；

• 单个接口：比如在我们的系统有一些聚合接口，提供给外部，有新的需求时，可能只用其中一个字段，就直接调接口取了；

• OOP中的接口概念：主张多继承，不要把一坨都写到一个接口里；

特点：

• 一个类对另外一个类的依赖应当是建立在最小的接口上；

• 客户端不应该依赖它不需要的接口方法/功能；

• 接口实现尽可能的单一，不要依赖不需要的；

• 接口隔离和单一职责的区别：

• 单一职责是针对的模块、类、接口的设计；

• 接口隔离原则提供了一种判断接口的职责是否单一的标准；

实现目的：基于调用者考虑，低耦合、确保最小依赖/调用/使用；

依赖倒置原则

定义：高层模块不要依赖低层模块，高层模块和低层模块应该通过抽象来相互依赖。

在之前的DDD应用框架中，基础设施层就依赖倒置了domain层；

特点：

• 高层不依赖低层模块，共同依赖同一个抽象

• 抽象不关注具体的实现细节，具体实现细节依赖于抽象；

实现目的：指导框架层面的设计

迪米特法则 LOD Law of Demeter

定义：不该有直接依赖关系的类之间，不要有依赖，有依赖关系的类之间，尽量只依赖必要的接口；

特点：

• 不该有直接依赖关系的，不要有依赖；

• 有依赖的，尽量只依赖必要的接口；

实现目的：基于类关系，高内聚、松耦合

DRY 原则 Don’t Repeat Yourself

定义：不要写重复的代码。

特点：

• 代码复用

• 减少代码藕合

• 满足单一职责

• 模块化

• 业务与非业务逻辑分离

• 继承、多态、抽象、封装

• 应用模板等设计模式将功能拆解为原子方法；

实现目的：代码复用

KISS 原则

定义：尽可能的保持简单

• Keep It Simple and Stupid.

• Keep It Short and Simple.

• Keep It Simple and Straightforward.

特点：

• 代码足够简单，意味着通俗易懂，bug难隐藏

• 不要使用同事不懂的技术来实现代码

• 不要重复造轮子

• 不要过度优化

实现目的：保持代码的可读性和维护性