如何成为一名 Web 开发者。第三部分：面向对象设计
4.88/5 (5投票s)
Web 开发中的面向对象设计
在转向服务器端编程之前，有几个面向对象设计原则你应该了解。
这些原则并不是你能够完全理解的那种东西，直到你花时间去实践它们。 我现在介绍它们，因为当今流行的服务器端语言（包括 JavaScript）至少有一些 OO 特性。
在处理 OO 编程范例时，这些原则是通用的。 对于像 Haskell 这样的函数式语言，这些原则可能不太相关。
有关此系列中有关如何成为 Web 开发者的其他文章，请在此处和此处查看。
系好安全带，让我们开始吧。
对象设计：SOLID+D
让我们从如何设计类开始。
传统上有 5 个核心原则你应该尝试遵守（我喜欢包含第 6 个）。
- 单一职责 (SRP)
- 开闭原则
- 里氏替换原则
- 接口隔离原则
- 依赖倒置原则
- 迪米特法则
这些原则中的每一个都相当复杂，但如果你想成为一名 Web 开发者，理解它们至关重要。下面，我包含了一个简短的摘要，并附有论文和文章链接，这些链接出色地解释了其中的细微差别。
如果你在掌握这些概念时遇到困难，不要灰心。
正如我之前所说，这些可能需要一些时间才能完全理解，尤其是在你刚开始编程的时候。如果你想了解更多信息，请参阅 Uncle Bob 的这篇关于 OOAD 原则的资源文章。
这本书也深入探讨了这个主题。
单一职责 (SRP)
如果一个类有多个职责，那么这些职责就会耦合。一个职责的改变可能会损害或阻碍类满足其他职责的能力。这种耦合会导致脆弱的设计，在更改时以意想不到的方式中断。
开闭原则
当对程序的一次更改导致对依赖模块的一系列更改时，该程序会显示出我们已经习惯与“坏”设计相关的那些不良属性。程序变得脆弱、僵化、不可预测且不可重用。开闭原则以一种非常直接的方式解决了这个问题。
它表明你应该设计永远不会改变的模块。当需求发生变化时，你可以通过添加新代码来扩展这些模块的行为，而不是通过更改已经正常工作的旧代码。
里氏替换原则
当考虑违反它的后果时，这个原则的重要性就显而易见了——
违反它的后果。如果有一个函数不符合 LSP，那么该函数使用指向基类的指针或引用，但必须了解该基类的所有派生类。这样的函数违反了开闭原则，因为每当创建基类的新派生类时，都必须修改它。
接口隔离原则
这个原则处理了“臃肿”接口的缺点。“臃肿”接口的类是指接口不内聚的类。换句话说，类的接口可以分解为一组成员函数。每组服务于不同的客户群。因此，一些客户使用一组成员函数，而其他客户使用其他组。
ISP 承认存在需要非内聚接口的对象；然而，它建议客户端不应该知道它们作为一个单一的类。相反，客户端应该知道具有内聚接口的抽象基类。一些语言将这些抽象基类称为“接口”、“协议”或“签名”。
依赖倒置原则
这个原则处理了设计中的依赖流向。高层模块应驱动低层模块的变化，而不是反过来。如果低层模块驱动对高层模块的更改，那么简单的更改就会贯穿整个应用程序。这绝不是好事。
迪米特法则
基本概念是，给定对象应该尽可能少地假设任何其他对象的结构或属性（包括其子组件），根据“信息隐藏”原则。
打包原则
接下来，我们提高一个级别，看看如何将类组合成更大的组件。这将构成我们解决方案的宏观结构，并将影响可重用性和易于部署性。
设计包时最重要的两个因素是内聚性和耦合性。
- 内聚性是指包中的所有类之间的相关性有多密切。
- 耦合处理包之间的依赖流。
包内聚性
前三个包原则是关于包内聚性的，它们告诉我们应该将什么放入包中。
重用-发布等价原则 (REP)
这个原则帮助我们决定应该将哪些类放入一个包中。它指出，倾向于一起重用的类属于同一个包。类很少被孤立地重用。通常，可重用的类与构成可重用抽象的其他类协同工作。CRP 指出这些类应该在同一个包中。
共同重用原则 (CRP)
这个原则帮助我们决定应该将哪些类放入一个包中。它指出，倾向于一起重用的类属于同一个包。类很少被孤立地重用。通常，可重用的类与构成可重用抽象的其他类协同工作。CRP 指出这些类应该在同一个包中。
共同闭包原则 (CCP)
CCP 试图将所有可能出于相同原因而发生变化的类聚集在一个地方。如果两个类紧密耦合，无论是物理上还是概念上，以至于它们几乎总是一起变化；那么它们就属于同一个包。这最大限度地减少了与软件发布、重新验证和重新分发相关的工作量。
包耦合
最后三个原则是关于包之间的耦合，并讨论了评估系统包结构的度量。
循环依赖原则 (ADP)
应用程序中的依赖必须是一个有向无环图。换句话说，你的依赖结构中不能有循环。大多数强类型语言会检测到这一点并抛出错误，但了解为什么这可能是一个问题仍然很有用。
稳定依赖原则 (SDP)
任何我们期望易变的包都不应该被一个难以更改的包所依赖！否则，易变包也将难以更改。通过遵循 SDP，我们确保了设计为不稳定的模块（即易于更改）不会被比它们更稳定的模块（即更难更改）所依赖。
稳定抽象原则 (SAP)
这个原则在稳定性和抽象性之间建立了关系。它认为一个稳定的包也应该是抽象的，这样它的稳定性就不会妨碍它的扩展。另一方面，它认为一个不稳定的包应该是具体的，因为它的不稳定性允许其中的具体代码轻松更改。
结论
这些原则可能看起来非常技术化，并且在开始时可能有点难以理解。但它们非常值得努力去学习，因为对于任何想要超越简单应用程序的 Web 开发人员来说，它们都至关重要。
您有同事可能从本文中受益吗？如果有，请将本文转发给他们。
祝您好运，如有任何疑问，请随时在下方留言。
文章“如何成为一名 Web 开发者。第三部分：面向对象设计”首次出现在 Aesthetic IO。