图解S.O.L.I.D原则

如果您熟悉面向对象的编程，那么您可能已经听说过SOLID原理。

这五项软件开发原则是构建软件时要遵循的准则，以便于扩展和维护。 它们受到软件工程师Robert C. Martin的欢迎。

在线上有很多关于SOLID的精彩文章，但我很少看到带有图片的示例。 这使得像我这样的视觉学习者在保持参与的同时学习变得有些困难。

因此，本文的主要目的是通过插图并强调每种原理的目标来更好地理解这些原理。

您会看到，其中一些原则可能看起来很相似，但它们的目标并不相同。 即使它们是相同的，也可以在违反另一个原则的同时满足其中一个原则。

为了使操作简单，我将使用"类"一词，但请注意，本文中它也可以应用于函数，方法或模块。

更新*我收到了一些有关"封闭式开放"的评论，这违反了单一责任原则。 请注意，本文的目的是要独立于其他原则来解释这些原则。

此外，职责（或角色）与行动不同。 在SRP中，我使用"我是画家"，在"开闭式"中，我使用"我可以绘画"。

注意这一点很重要，因为可以执行多个操作来履行职责（或角色）。 该类应具有一个职责（SRP），但履行该职责的功能应开放以扩展（OCP）。

现在开始吧！

SOLID原则

S — 单一责任

类应负单一责任

 

如果一个班级承担许多责任，则增加了发生错误的可能性，因为更改其职责之一可能会在您不知情的情况下影响其他职责。

目标

该原则旨在区分行为，这样，如果您的更改导致错误出现，则不会影响其他无关的行为。

O — 开闭

类应该开放以进行扩展，而封闭以进行修改

 

更改类的当前行为将影响使用该类的所有系统。

如果要让类执行更多功能，理想的方法是将功能添加到已经存在的功能中，而不更改它们。

目标

该原则旨在扩展类的行为，而不改变该类的现有行为。 这是为了避免在使用Class的任何地方引起错误。

L- 利斯科夫替换原则

如果S是T的子类型，则可以将程序中类型T的对象替换为类型S的对象，而无需更改该程序的任何所需属性。

 

当子类无法执行与其父类相同的操作时，可能会导致错误。

如果您有一个类并从中创建另一个类，则该类将成为父类，而新的类将成为子类。 子类应该能够执行父类可以做的所有事情。 此过程称为继承。

子类应该能够处理与父类相同的请求并传递相同的结果，或者它可以传递相同类型的结果。

图片显示父类提供咖啡（它可以是任何类型的咖啡）。 子类交付Cappucino是可以接受的，因为它是一种特殊的咖啡，但是交付水是不可接受的。

如果子类别不符合这些要求，则意味着子类别已完全更改，并且违反了这一原则。

目标

该原则旨在加强一致性，以便可以以相同的方式使用父类或其子类，而不会出现任何错误。

I — 接口隔离

不应强迫客户依赖他们不使用的方法。

 

当要求一个类执行无用的操作时，这是浪费的，并且如果该类没有执行那些操作的能力，则可能会产生意外的错误。

类应仅执行履行其职责所需的操作。 如果将来其他班级可能会使用其他任何动作，则应将其完全删除或移至其他位置。

目标

该原则旨在将一组动作分成较小的一组，以便Class仅执行其所需的一组动作。

D — 依赖倒置

-高级模块不应依赖于低级模块。 两者都应取决于抽象。

-抽象不应依赖细节。 细节应取决于抽象。

 

首先，让我们更简单地定义此处使用的术语

高级模块（或类）：使用工具执行动作的类。

低级模块（或类）：执行操作所需的工具

抽象：表示连接两个类的接口。

详细信息：该工具如何工作

该原则表明，不应将类与用于执行动作的工具融合在一起。 而是应将其与允许工具连接到类的接口融合。

它还说，类和接口都不应该知道工具的工作方式。 但是，该工具需要满足接口规范。

目标

该原理旨在通过引入接口来减少高级类对低级类的依赖性。

摘要

到目前为止，我们已经讨论了这五个原则并突出了它们的目标。 它们将帮助您使代码易于调整，扩展和测试，几乎没有问题。

非常感谢您的阅读。 我希望您对这个主题有个更好的主意，并且阅读时和我编写时一样开心。

如果您有任何疑问或建议，请发表评论或通过Twitter @ ugonna_t与我联系。

(本文翻译自Ugonna Thelma的文章《The S.O.L.I.D Principles in Pictures》，参考：https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898)