SOLID原则

SOLID原则是面向对象编程（OOP）遵循的5条规则。 这些规则或原则可用于创建易于扩展和维护，同时避免代码异味并允许简单重构的软件。 显然，这5条原则并不是灵丹妙药，它们不会修复任何代码库或使您的代码库变得神奇。 即使遵循这些规则，您也可以编写使维护和重构变得困难的代码。 这些规则应成为设计和编写软件时要牢记的好东西，但它们也可以与编码准则和其他概念（例如设计模式）结合使用。

我将在这篇文章中介绍所有5条原则，但也将链接到其他文章，在其中我将通过代码示例和代码片段更深入地解释每项原则。 如果您不懂OOP或想复习一下，建议您在继续之前阅读这些帖子，在其中解释OOP的基本知识。

Classes and Objects

一世nterfaces and Abstract Classes

一世nheritance and Polymorphism

Single Responsibility Principle

单一责任原则（SRP）可能是5条原则中最容易理解的。 每个班级应该只有一份工作。 这似乎很简单，即使开发人员努力遵循它，大多数开发人员也可以告诉您。 用这个原理很难理解的是，一个类的单一职责可以是非常具体的，也可以抽象一些。 例如，您可能有一个类，其目的是保存矩形的数据，它的大小和位置，但是对于一个类，您可以拥有一个更通用的类，该类既保存矩形的所有数据，又处理计算 这是面积和周长。 第二个示例可以执行多个任务，可以计算其面积或周长，但仍然只有一个职责-处理矩形。 如果同一类也处理了用户签名，则它不再承担责任，因此会破坏SRP。

关于单一责任原则要记住的重要一件事是，每个类都应为现有存在一个明确定义的目的，并且只能做一件事。 这件事可能非常具体，例如处理一个矩形，或者更通用一些，并且具有多种操作（例如处理用户身份验证）。 该原理也可以扩展到较小的范围，每个类应具有单一目的，并且该类中的每个方法应具有更特定的单一目的。

Read more about the Single Responsibility Principle here.

Open-Closed Principle

开放-封闭原则指出对象应为扩展而开放，而为修改而封闭。 这意味着任何对象也应该易于扩展或添加功能，但不应对其进行修改或更改。 开始时很难理解这个原理，因为在OOP范式之外它是没有意义的。 假设我们有一段处理特定功能的代码，然后编译该代码，以使我们无法对其进行更改。 我们应该能够在代码中添加功能，以使其可以扩展扩展，而无需修改源代码，而可以将其关闭以进行修改。 显然，在OOP之外，这是不可能的，因为要添加功能，我们必须首先更改源代码，然后重新编译代码。 但是，在OOP中，您可以使用类的编译源并在新类中从其继承-新类将是预编译类的子代。 从基类继承可以使您添加基类不具备的功能，还可以使基类保持修改状态。 简而言之，从基类继承时，您不必更改或修改基类。

Read more about the Open-Closed Principle here.

Liskov Substitution Principle

Liskov替换原则指出，在使用基类的任何位置都应该可以替换任何子类。 这意味着，如果您的代码中有一个地方使用基类，或者任何有子类的类，那么应该可以使用其任何子类而无需破坏代码或更改代码。 如果您将基类替换为其任何子类的实现，则不应有任何不同，也不要创建错误或错误。 该原则确保了继承树实际上遵循正确的继承关系，并迫使您考虑继承层次结构，而不仅仅是从基类扩展到复制功能。

Read more about the Liskov Substitution Principle here.

Interface Segregation Principle

接口隔离原则指出，不应强迫类实现其不使用的接口或方法，或者在这种情况下不可行的接口或方法。 在OOP上下文中进行编码时，通常会使用多态性，因此可以在许多不同的具体实现中使用通用代码。 但是，这可能导致使类实现接口以允许多态性，而这实际上是没有意义的。 例如，处理联系信息的类不应从处理人的工资或时薪的类或接口中实现。 人们违反接口隔离原则的另一个原因是因为他们的接口中包含太多的方法。 假设您有一个接口，该接口可以强制实现两种方法“ talk”和“ fly”，这两种方法将用于不同类型的鸟的实现。 但是，有些鸟不会飞，因此，如果为Dodo鸟创建一个类，则会从此接口实现，然后被迫实现在这种情况下没有意义的“ fly”方法。 这并不意味着每个接口都应该只有一个方法。 将您的接口分解为合理大小的组件是一件困难的事情，并且很可能导致以后重构您的代码库。 实体组件系统设计模式是接口隔离原理的一个很好的例子。

Read more about the Interface Segregation Principle here.

Dependency Inversion Principle

依赖倒置原则指出，任何实体都应依赖抽象而不是具体的实现。 这意味着您应该使用多态性使您的类依赖于接口或抽象类，而不是依赖项的具体实现。 这使您可以轻松换出具体的实现，而不必重构您的基类。 这是遵循的有用规则，但是它很快就会失控，因为您可以为代码库中的每个具体类创建一个接口。

Read more about the Dependency Inversion Principle here.

SOLID原则是遵循的重要规则，可以使您的代码库易于维护，扩展和避免气味。 但是，采用这些原则中的任何一项并与其一起运行实际上会使您的代码库更糟。 例如，使您的代码完全不受修改，将防止任何重构或功能更改，使每个具体类都依赖于接口，这将导致庞大的代码库需要管理，等等。重要的是检查代码库，如果不能 完全遵循可以的原则。 与许多与软件相关的技巧和窍门一样，将它们视为良好的准则，而不是必须完全遵循的严格制度。

This post was originally published on https://acroynon.com

from: https://dev.to//acroynon/the-solid-principles-15a5