React 中的组件设计原则

一般来说，好的代码的特点是混合了三样东西：

• 功能性：代码组合在一起以创建所需的功能。
• 可维护性：很容易进行更改、添加新功能以及让其他开发人员理解代码的功能。
• 健壮的：由于有一个很好的测试套件，软件很难被破坏，并且在错误发生时会适当地处理错误。

然而，这引出了我们如何才能实现这三件事的问题。随着软件行业的发展，它从过去的错误中吸取了教训。在这样做的过程中，已经开发了许多“经验法则”来帮助软件实现这三个目标中的一个（如果不是全部的话）。这些“经验法则”就是我们所说的最佳实践、软件开发哲学或设计原则。这些旨在成为一种适用于所有系统的软件开发方法，因此熟悉这些设计原则将有助于您以任何语言或范式编写代码。

然而，由于它们的普遍性，设计原则在很大程度上取决于开发人员如何严格遵守它们。过于强烈地遵循任何一种设计原则最终都会对上述三个目标产生适得其反的效果。找到这种平衡取决于编程语言、风格、个人品味、要求、时间和许多其他因素。因此，每个开发人员/团队都有责任找到适合他们的方法。也就是说，如果您目前没有遵循任何设计原则，那么将它们实施到您的代码中几乎肯定有助于实现上述三个目标之一。

本文将主要介绍软件设计的 SOLID 原则，以及我们如何使用它们来使用 React 编写更好的前端。

软件设计原则的存在是为了让我们的代码更实用、更易于维护和/或更健壮。它们是基于过去智慧的经验法则，几乎适用于您从事的任何语言/范例/项目。它们不会为您提供任何特定的编程知识，但它们可能是您可以找到的最好的“物有所值”的工具，可以帮助您培养编写实用、简洁和健壮的软件的能力。

免责声明

软件设计原则很棒，因为它们与语言无关；无论您使用何种语言编写，它们都可以应用。但是，无法回避的事实是，SOLID 设计原则源自 2000 年Robert Martin 的设计原则和模式论文中的面向对象类设计原则。[1] JavaScript - 虽然能够使用其原型系统支持伪 OO 风格 - 缺乏 OO 语言的一些显着特征（例如，适当的类和接口）。[2]尤其是 React 库更多地植根于函数式编程范式而不是 OOP 范式，尤其是钩子系统及其对闭包的依赖。[3]因此，我们不能将在 Java/C# 中应用的 SOLID 原则的示例直接翻译成 JavaScript，并且我们不应该假装 JavaScript/React 不是。我们根本不会像在 Java 中那样在 React 中编写前端。就像翻译一种语言一样，我们必须了解每个原则试图做什么，然后将其映射到前端 Web 开发，这样它的意义就不会丢失。这意味着此处每个 SOLID 原则的应用可能不同于它们在严格的 OO 语言中的原始实现. 然而，我已经尽力找到一种相应的方法将每个原则转化为一些有意义的想法，我们可以在使用 React 构建前端时使用这些想法，而不是只是鹦鹉学舌地定义每个原则。

我们可以使用 SOLID 原则来编写更好的 React 前端，但是我们必须使用某些语言自由来提取适用的实现。

什么是固体？

SOLID 是五个独立设计原则的首字母缩写词：

• 单一责任原则 (SRP)。
• 开放/封闭原则 (OCP)。
• Liskov替换原则 (LSP)。
• 接口隔离原则 (ISP)。
• 依赖倒置原则（DIP）。

这些听起来很花哨，但是我们可以在用 React 编写前端时将它们映射到特定的实现：

• SRP：每个函数/类/组件都应该只做一件事。
• OCP：您应该能够向某些模块添加功能，而无需修改其现有源代码（更喜欢组合而不是继承）。
• LSP：如果 B 扩展了 A，那么在任何你使用 A 的地方你都应该能够使用 B。
• ISP：不要让组件依赖于它不关心的道具。
• DIP：高级代码不应依赖于实现细节——始终使用抽象。

上面展示了我们在编写现代 React 代码时可以实现每个原则的方法（例如 - 在类上使用钩子）。让我们详细了解每一个，并解释这些语句的含义！参考第二个章节。