软件架构设计原则

软件架构设计原则

---

简介

SOLID原则

单一责任原则（Single Responsibility Principle，SRP）

• 定义
  一个类应该只有一个引起它变化的原因。换句话说，一个类应该只有一个职责。
• 举例说明
  假设我们有一个名为User的类，它负责用户的注册和登录。根据单一责任原则，我们应该将这两个职责拆分为两个不同的类：UserRegistration和UserLogin。这样可以让每个类专注于自己的职责，提高代码的可维护性和可扩展性。

开放封闭原则（Open-Closed Principle，OCP）

• 定义
  软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。即在不修改现有代码的情况下，通过添加新代码来扩展功能。
• 举例说明
  假设我们有一个名为Shape的抽象类，它有一个draw()方法用于绘制形状。现在我们想要添加一个新的形状，例如矩形。根据开放封闭原则，我们应该通过创建一个继承自Shape的Rectangle类来扩展功能，而不是修改Shape类的代码。这样可以保持原有的代码稳定性，同时扩展新功能。

里氏替换原则（Liskov Substitution Principle，LSP）

• 定义
  子类型必须能够替换其基类型，而程序的行为不会发生变化。即任何接受基类型对象的地方都可以接受子类型对象，而不会产生错误或异常。
• 举例说明
  假设我们有一个基类Animal和它的子类Dog和Cat。根据里氏替换原则，我们应该能够将Dog和Cat对象传递给接受Animal对象的方法，而不会引发错误或异常。例如，如果有一个方法feed(Animal animal)用于喂养动物，我们可以传递Dog或Cat对象给该方法而不会导致问题。

接口隔离原则（Interface Segregation Principle，ISP）

• 定义
  客户端不应该强制依赖它们不需要的接口。接口应该精确地定义客户端所需的方法。
• 举例说明
  假设我们有一个接口Printer定义了打印相关的方法，包括print()和scan()。但是在某些场景下，我们只需要打印功能而不需要扫描功能。根据接口隔离原则，我们应该将Printer接口拆分为Printable和Scannable两个接口，这样客户端只需要依赖需要的接口即可，避免了不必要的依赖和方法实现。

依赖倒置原则（Dependency Inversion Principle，DIP）

• 定义
  高层模块不应该依赖低层模块，两者都应该依赖于抽象。即依赖关系应该建立在抽象上而不是具体实现上。
• 举例说明
  假设我们有一个高层模块UserService依赖于低层模块UserRepository来获取用户数据。根据依赖倒置原则，我们应该定义一个抽象接口UserRepository，让UserService依赖于抽象接口而不是具体的实现类。这样可以降低模块之间的耦合性，提高代码的可维护性和可扩展性。

KISS原则（Keep It Simple, Stupid）

保持简单，不要过度设计，保持代码简洁易读。

YAGNI原则（You Ain’t Gonna Need It）

不要为未来的需求而做过度的设计，只关注当前的需求。

DRY原则（Don’t Repeat Yourself）

避免重复代码，将重复的逻辑提取到可复用的组件中。

高内聚低耦合原则

模块应该具有高内聚性，模块之间应该具有低耦合性，以实现代码的独立性和可维护性。

GRASP原则（General Responsibility Assignment Software Patterns）

• 高内聚和低耦合
• 创建者
• 信息专家
• 低耦合
• 控制器
• 多态性
• 纯粹的制造者
• 保护性包装器