底层设计和SOLID原则

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

底层设计（LLD）是软件开发中的一个关键阶段，它弥合了高层设计与实际实现之间的鸿沟。高层设计侧重于架构蓝图，而底层设计则关注如何实现每个组件、类或功能以满足整个系统的需求。

简而言之，低级设计（LLD）涉及类、方法、接口以及它们之间的交互设计，确保代码高效、易于维护和可扩展。对于软件工程师而言，这是一项至关重要的技能，尤其是在构建需要具备健壮性、可重用性和易于长期修改性的系统时。

本博客将向您介绍底层设计中的关键概念、原则和技术，并展示它们如何帮助您编写更好、更易于维护的代码。

我们脑海中浮现的第一个问题是：

为什么底层设计很重要？

1. 可维护性：精心设计的代码更易于维护、扩展和调试。糟糕的设计会导致技术债务，使未来的变更成本高昂。
2. 可扩展性：良好的低级设计 (LLD) 可确保代码具有可扩展性，无论是在性能方面，还是在系统演进过程中支持新功能方面。
3. 可重用性：设计良好的组件可以在系统的不同部分或完全不同的项目中重复使用。
4. 清晰性：有了明确的设计，工程师就能了解系统的各个部分是如何组合在一起的，从而更容易进行协作。

为了弥合低级设计概念与实际代码之间的差距，让我们通过以下步骤来分解低级图的设计过程：

第一步：面向对象原则；
第二步：SOLID 原则；
第三步：设计模式

面向对象原则

面向对象编程概念的四大支柱是学习底层设计的必备知识。我已经在博客中简要介绍过这个概念，欢迎查看。

SOLID 原则

S：单一职责原则（SRP）

• 每个代码单元应该只负责一项修改。
• 单元可以是类、模块、函数或组件。
• 保持代码模块化，降低紧耦合性。

例如：假设有一个类同时处理用户身份验证和日志记录。如果我们需要更改日志记录的工作方式，最终也需要修改身份验证类。这违反了单一职责原则（SRP）。相反，我们应该使用两个独立的类：一个用于用户身份验证，另一个用于日志记录，这样每个类都只负责一项职责。

O：开闭原理（OCP）

• 代码单元应该允许扩展，但不允许修改。
• 通过添加新代码来扩展功能，而不是修改现有代码。
• 适用于基于组件的系统，例如 React 前端。

例如：假设有一个处理信用卡支付的支付系统。如果您需要添加对 PayPal 的支持，与其修改现有代码，不如通过添加一个新的 PayPal 支付类来扩展现有代码。这样既能确保现有系统的稳定性，又能允许添加新功能。

L：里氏替换原理（LSP）

• 子类应该能够替代其基类。
• 基类中的功能应该能够被所有子类使用。
• 如果子类不能使用基类的功能，那么它就不应该存在于基类中。

例如：如果我们有一个 Bird 类，它有一个 fly() 方法，然后我们创建了一个子类 Penguin，而 Penguin 不能飞，这就违反了 LSP 原则。Penguin 类不应该继承 fly() 方法，因为它改变了预期的行为。相反，应该重构 Bird 类，使其能够以不同的方式处理可以飞和不能飞的鸟类。

I：接口隔离原则（ISP）

• 提供多个专用接口，而不是少数几个通用接口。
• 客户不应该依赖他们不使用的方法。

例如：假设我们有一个名为 Animal 的接口，其中包含 fly()、swim() 和 walk() 方法。实现了 Animal 接口的 Dog 类将被迫定义 fly() 方法，而它并不需要这个方法。为了遵循 ISP 原则，我们应该将 Animal 接口拆分成更小的接口，例如 Flyable、Swimmable 和 Walkable，以避免在类中强制定义不相关的方法。

D：依赖倒置原理（DIP）

• 要依赖抽象概念，而不是具体的类。
• 利用抽象来解耦系统各部分之间的依赖关系。
• 避免代码单元之间直接调用，使用接口或抽象。

例如：在电子商务应用中，如果结账流程（高层模块）直接依赖于特定的支付网关（例如 PayPal，底层模块），那么更换支付网关就需要修改结账流程。通过引入抽象层（例如 PaymentProcessor 接口），结账流程就可以兼容任何支付方式，而无需了解 PayPal 或其他服务的具体细节。

设计模式

设计模式是针对软件设计中常见问题的成熟解决方案。它们是开发人员可以遵循的最佳实践，能够高效、系统地解决特定的设计问题。设计模式无需重复造轮子，而是为解决反复出现的问题提供了一种标准方法。

设计模式可以分为三种类型：

1. 创建模式：处理对象创建

   • 工厂设计模式
   • 抽象工厂设计模式
   • 建造者设计模式
   • 原型设计模式
   • 单例设计图案

2. 结构模式：处理对象的组成和关系

   • 适配器模式
   • 桥接模式
   • 复合图案
   • 装饰图案
   • 立面图案
   • 轻量级模式
   • 代理模式

3. 行为模式：处理与物体的交互和责任

   • 责任链模式
   • 命令模式
   • 解释器模式
   • 调解员模式
   • 纪念图案
   • 观察者模式
   • 状态模式
   • 策略模式
   • 模板方法模式
   • 访客模式

编写代码时，通常会遇到三种主要类型的问题：

对象创建：

首要挑战在于如何创建对象。
这时，创建型设计模式就派上了用场。例如：
工厂模式、抽象工厂模式、单例模式、建造者模式等等。这些模式都与对象的创建有关。

对象关系：

创建对象之后，下一个问题是：它们之间将如何关联？
你需要决定如何将这些对象组织成一个更大的系统或模块。这时，结构化设计模式就派上了用场。例如：外观模式、组合模式、适配器模式等，
这些模式有助于定义对象之间的关系和结构。

对象通信：

最后，你需要确定对象之间如何通信以及每个对象承担哪些职责。
你想要不同的时间行为，还是对象链？
行为设计模式可以解决这个问题。例如：策略模式、命令模式、观察者模式
。这些模式管理对象通信和行为委派。

现在我们已经通过探索 SOLID 原则打下了基础，并介绍了设计模式的广阔领域，接下来我们将深入学习！在接下来的系列文章中，我将结合实际示例和真实场景，逐一剖析每一种设计模式。无论你是刚刚踏上设计之旅，还是希望精进技能，这些模式都能帮助你编写更简洁、更具可扩展性的代码。敬请期待下一篇博客，我们将一步步揭秘第一个设计模式！

如果你看到了这里，别忘了点赞❤️，并在下方留言提出你的问题或想法。你的反馈对我非常重要，我非常期待听到你的声音！