“It is not enough for code to work.”― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“仅代码工作是不够的。”- Robert C. Martin， 清洁代码：敏捷软件Craft.io手册

Before we will start investigating what are the five S.O.L.I.D. principles, I would like to say a few words about Technical debt:

在我们开始研究SOLID的五项原则之前，我想谈一谈技术债务：

You can find a lot of articles about it, but I want to share with you with the simplest explanation:

您可以找到很多关于它的文章，但是我想与您分享最简单的解释：

Technical debt — it’s the result of prioritizing speedy delivery over perfect code.

技术债务 -这是优先考虑快速交付而不是完美代码的结果。

技术债务情况： (Technical Debt Facts:)

• No matter how good your team is, technical debt will accumulate over time;

  无论您的团队多么出色， 随着时间的推移 ， 技术债务都会累积 ；

• Left uncontrolled, technical debt will kill your project;

  如果不加控制， 技术债务将扼杀您的项目 ；

• If you want to keep it under control - use SOLID principles, during your development.

  如果要控制它-在开发过程中使用SOLID原理。

I will not describe what are the Rigidity, Coupling, Immobility, and Viscosity. Those are the consequences of not using SOLID. You could find a lot of nice articles about those, so I won't focus on them, but I will give you short definitions for understanding if you are not familiar with them:

我不会描述什么是刚性 ， 耦合，固定性 ， 和粘度 。 这些是不使用SOLID的后果。 您会发现很多关于这些的不错的文章，所以我不会专注于它们，但是如果您不熟悉它们，我将为您提供简短的定义以供理解：

• Rigidity — implementation that is difficult to change;

  刚性 - 难以改变的实施方式 ；

• Fragility — implementation that is easy to break;

  脆弱性 - 易于破解的实现 ；

• Immobility — implementation that is difficult to reuse;

  固定性 - 难以重用的实现 ；

• Viscosity — it is difficult to implement new features the right way;

  粘性 - 很难以 正确的方式 实现新功能；

干净代码金字塔 (Pyramid of clean code)

The SOLID principles are the foundation of clean system design

SOLID原则是清洁系统设计的基础

SOLID原则 (SOLID Principles)

SOLID — acronym for 5 software design principles that help us to keep technical debt under control.

SOLID-5个软件设计原则的缩写，可帮助我们控制技术债务。

The purpose of SOLID is to make you more productive, by making your code more maintainable through decomposition and decoupling.

SOLID的目的是通过分解和解耦使代码更具可维护性，从而提高工作效率。

1. Single Responsibility Principle (SRP);

   小号英格尔职责原则(SRP);

2. Open Closed Principle (OCP);

   O封闭原则(OCP)；

3. Liskov Substitution Principle (LSP);

   大号 iskov替换原则(LSP);

4. Interface Segregation Principle (ISP);

   我覆盖整个院落隔离原则(ISP);

5. Dependency Inversion Principle (DIP);

   d ependency倒置原则(DIP);

1.单一责任原则(SRP) (1. Single Responsibility Principle (SRP))

Every function, class or module should have one, and only one reason to change.

每个函数，类或模块都应该有一个 ，并且只有一个更改的理由。

One reason to change => one responsibility!

改变的一个理由=>一种责任！

“Separation of concerns” — do one thing, and do it well!

“关注点分离” —做一件事，做得好！

Symptoms of Not using SRP:

不使用SRP的症状：

• Code is difficult to read and understand (we spend 90% of time reading and understanding code);

  代码难以阅读和理解(我们花费90％的时间阅读和理解代码)；

• “God class” or ”Monster method” (class/method that does Logging, Caching, Connecting to Database, Read/Write files, sending commands to space shuttles, etc.);

  “ 神级 ”或“ 怪物方法 ”(执行日志，缓存，连接数据库，读/写文件，向航天飞机发送命令等的类/方法)；

• Side effects;副作用;
• High coupling;高耦合；
• IF/SWITCH statements — a clear sign that a method has multiple reasons to change;IF / SWITCH语句-明确表明方法具有多种更改原因；

让我们看一下不使用SRP的代码示例… (Let’s see on examples of code where SRP is not used…)

As you can see UserController’s save() method is doing four things instead of one — saving one user to the database.

如您所见，UserController的save()方法执行的是四件事而不是一件事–将一个用户保存到数据库中。

And I agree that we can't just throw away logging from this example (what if we NEED to log this process step-by-step), but my point here is we are logging to the console here. But what if we will decide log to file, or send by email, or via social network, etc.

而且我同意我们不能仅仅从该示例中放弃日志记录(如果需要逐步记录该过程，该怎么办)，但是我的意思是我们要在此处登录控制台。 但是，如果我们决定将日志记录到文件，通过电子邮件或通过社交网络等发送，该怎么办？

How we can improve our code here?

我们如何在这里改善代码？

1. Do not create an instance of PostgreSQL class with connect() method. This method should be responsible only for saving User to a database, it should not do any additional tasks.

   不要 创建的PostgreSQL类与实例 connect()方法。 此方法仅应负责将用户保存到数据库，而不应执行任何其他任务。

2. Do not create an instance of a User(I think this is obvious);

   不要创建 User 的实例 (我认为这很明显)；

3. Do not create an instance of a Logger(console);

   不要创建 Logger(console) 的实例 ；

As you probably noticed, the main cause of problems could appear because of Coupling — our save() method doing not related tasks by itself. We can solve this problem by using abstractions: abstract connection and abstract logger (interfaces or abstract classes):

您可能已经注意到，问题的主要原因可能是由于耦合引起的-我们的save()方法本身并不执行相关任务。 我们可以通过使用抽象来解决此问题： abstract connection和abstract logger (接口或抽象类)：

And the final result would look like this:

最终结果将如下所示：

You probably think that this solution is overcomplicated and we can just pass connection and logger as simple arguments, but here I used another principle that is not a part of a SOLID, but will help you a lot, is you will use it — Reused Abstraction Principle.

您可能会认为此解决方案过于复杂，我们只能将connection和logger作为简单参数传递，但是在这里我使用了另一个原则，该原则不是SOLID的一部分，但会帮到您很多，您将使用它吗？- 重用抽象原理 。

As you can see UserController doesn’t know anything about database, it can be PostgreSQL, MySQL, MongoDB, etc.

如您所见， UserController对数据库一无所知，可以是PostgreSQL ， MySQL ， MongoDB等。

Same with logger. UserController doesn’t know anything about the destination of a log: console, file, sms, email, etc:

与logger相同。 UserController对日志的目标一无所知： console ， file ， sms ， email等：

And the main thing:

最主要的是：

Save method only saves some “User” to some “Database”.

保存方法仅 将一些“用户” 保存到一些“数据库”中。

Mission complete!

任务完成！

Rule of three: the rule of three is really a rule that was originally stated in context of refactoring, and essentialy it says: “You should not try to introduce a general purpose solution to something until you have three cases that fit into the same generalization”.

第三规则：第三规则实际上是最初在重构上下文中陈述的规则，本质上它说：“除非您有三个适合同一概括的案例，否则您不应该尝试为某个问题引入通用解决方案。 ”。

“Developers have a tendency to attempt to solve specific problems with general solutions. This leads to coupling and complexity. Istead of being general, code should be specific” — Greg Young

“开发人员倾向于尝试使用通用解决方案解决特定问题。 这导致耦合和复杂性。 而不是通用，代码应该是特定的” – Greg Young

If “ModuleA” knows too much about “ModuleB”, changes to “ModuleB” may break functionality in “ModuleA”.

如果“ModuleA”知道太多关于“ModuleB”，改变为“ModuleB”可以在“ModuleA”断功能。

2.开放式封闭原则(OCP) (2. Open Closed Principle (OCP))

This principle is mostly used for Production! Like for open-source libraries. The main idea is that if you created and published some class — changes in this class can break the implementation of those, who are started using this class.

这个原理主要用于 生产 ！ 像开源库一样。 主要思想是，如果您创建并 发布了 某个类 ，那么 对此类的更改可能会破坏那些开始使用此类的人员的实现。

Classes, functions, or modules should be opened for extensibility, but closed for modification.

应该打开类，函数或模块以实现可扩展性 ，但是应该关闭类以进行修改 。

• Each new feature should not modify existing source code;每个新功能都不应修改现有的源代码。
• A component should be extendable to make it behave in new ways.组件应该是可扩展的，以使其以新的方式运行。

When you written a class and put the class into production or other client rely on that class, you are no longer allowed to make changes to that class.

当您编写一个类并将该类投入生产或其他依赖该类的客户端时，将不再允许您对该类进行更改。

Bug fixing is OK.

错误修复是可以的。

Example of OCP using Design Patterns — Decorator pattern.

使用设计模式的OCP 示例 - 装饰器模式 。

OCP principle was originally described in the context of Inheritance.

OCP原理最初是在继承上下文中描述的。

Prefer Composition over Inheritance as it is more malleable/easy to modify later, but do not use a compose-always approach.

优先考虑组成而不是继承，因为以后更容易修改/更容易修改，但不要使用总是组合的方法。

Why should you apply the OCP:

为什么要应用OCP：

• New features can be added easily and with minimal cost新功能可以轻松添加且成本最低
• Minimize the risk of regression bugs最小化回归错误的风险
• Enforces decoupling by isolating changes in specific components, works along with the SRP通过隔离特定组件的更改来实现去耦，与SRP一起使用

SOLID principles are most effective when applied together

SOLID原则结合在一起使用最有效

好的OCP的两种方法： (Two ways of good OCP:)

• Inheritance. But we will get another problem — coupling.遗产。 但是我们会遇到另一个问题-耦合。
• Strategy Design Pattern策略设计模式

是否应每次使用OCP？ 没有： (Should OCP be used every time? No:)

1. Start small -> Make changes inline从小开始->内联进行更改
2. More changes -> Consider inheritance更多更改->考虑继承
3. Many changes/dynamic decision -> consider interface and design patterns like Strategy许多变更/动态决策->考虑接口和设计模式，例如策略

更改API的最佳做法 (Best practice for changing APIs)

• Do not change existing public contracts: data classes, signatures;不要更改现有的公共合同：数据类，签名；
• Expose abstractions to your customers and let them add new features on top of your framework;向您的客户公开抽象，并让他们在您的框架之上添加新功能；
• If a breaking change is inevitable, give your clients time to adapt.如果必须做出重大改变，请给您的客户一些时间来适应。

3. Liskov替代原理(LSP) (3. Liskov Substitution Principle (LSP))

Subtypes must be substitutable for their base type.

子类型必须可以替代其基本类型。

This principle is how Polymorphism should work, not how it actually works, but how it should work. Polymorphism -> is all about changing the behavior.

这个原则是多态性 应该如何工作，而不是它实际如何工作，而是它应该如何工作 。 多态 ->与改变行为有关。

Consume any implementation without changing the correctness of the system.

在不更改系统正确性的情况下使用 任何实现。

何时违反LSP？ (When is the LSP violated?)

• Type checking is a symptom of not implementing LSP;

  类型检查是未实现LSP的症状；

• LSP is often violated by attempts to remove features.

  尝试删除功能通常会违反LSP。

What does this mean is that more interface members you have, then more likely it becomes that there are one or more of those members that you’d like to remove. More members — more likely it is that you have a violation of the Liskov Substitution Principle.

这意味着您拥有更多的接口成员，那么您就有可能要删除一个或多个这些成员。 成员更多-您很可能 违反 了《里斯科夫换人原则》 。

Reused Abstraction Principle compliance indicates Liskov Substitution Principle compliance.

重用的抽象原理 符合性表示Liskov替代原理 符合性 。

让我们看一些LSP违反示例： (Let's look on some LSP violation examples:)

Example 1:

范例1：

class Bird{  public void fly(int altitude){    setAltitude(altitude);    // FLY logic  }}class Ostrich extends Bird {  @Ovveride  public void fly(int altitude){   // do nothing; an ostrich can't fly  }}Bird ostrich = new Ostrich();ostrich.fly(1000);

Example 2:

范例2：

class Rectangle{}class Square extends Rectangle{}

Example 3:

范例3：

将代码重构为LSP的两种方法 (Two ways to refactor code to LSP)

• Eliminate incorrect relations between objects;消除对象之间的错误关系；
• Use “Tell, don’t ask!” principle to eliminate type checking and casting;使用“告诉，不要问！” 消除类型检查和转换的原理；

主动应用LSP (Apply the LSP in a proactive way)

• Make sure that a derived type can substitute its base type completely;确保派生类型可以完全替代其基本类型；
• Keep base classes small and focused;保持基类小而专注；

• Keep interfaces lean (Moveable, Iterable, Readable)

  保持界面精简( Moveable ，可Iterable ， Readable )

4.接口隔离原理(ISP) (4. Interface Segregation Principle (ISP))

Clients should not be forced to depend on methods that they do not use.

客户应该not被迫依赖于方法，他们不使用。

The “interface” word in the principle name does not strictly mean an interface, it could be an abstract class .

原则名称中的“接口”一词并不严格表示接口 ，它可以是抽象类 。

Prefer “Role Interfaces” (Readable, Iterable, etc. Ideal “Role Interface” has only one member) over “Header Interfaces”/”Fat interfaces” (interfaces with save(), read(), update(), move(), etc members)

与“ Header接口” /“ Fat接口” (具有save()，read()，update()，move()的Iterable ，更喜欢“角色接口” ( Readable ， Iterable等。理想的“ Role接口”只有一个成员) ，等等成员)

Example:

例：

ISP加强了其他原则： (The ISP Reinforces Other Principles:)

• By keeping interfaces small, the classes that implement them have a higher chance to fully substitute the interface (ISP <-> LSP);

  通过使接口保持较小，实现接口的类有更大的机会完全替代接口( ISP <-> LSP )；

• Classes that implement small interfaces are more focused and tend to have a single purpose (ISP <-> SRP);

  实现小型接口的类更加集中并且往往具有单一目的( ISP <-> SRP )；

应用ISP的好处 (Benefits of applying the ISP)

• Lean interfaces minimize dependencies on unused members and reduce code coupling;精益接口最大程度地减少了对未使用成员的依赖，并减少了代码耦合；
• Code becomes more cohesive and focused;代码变得更具凝聚力和针对性；

• It reinforces the use of the SRP and LSP;

  加强了SRP和LSP的使用；

界面污染的症状 (Symptoms of interface pollution)

• Interfaces with lots of methods有很多方法的接口
• interfaces with low cohesion;内聚力低的界面；
• Client throws an exception instead of implementing a method;客户抛出异常而不是实现方法；
• Client provides an empty implementation;客户提供了一个空的实现；
• Client forces implementation and becomes highly coupled;客户迫使实施并高度耦合；

修复界面污染 (Fixing interface Pollution)

您自己的代码： (Your own code:)

Breaking interfaces is pretty easy and safe due to the possibility to implement as many interfaces as we want.

中断接口非常容易且安全，因为可以实现所需数量的接口。

外部旧版代码： (External legacy code:)

You can’t control the interface in the external code, so you use design patterns like “Adapter”

您无法在外部代码中控制界面，因此您使用的设计模式为“适配器”

Many client-specific interfaces are better than one general-purpose interface.

许多特定于客户端的接口比一个通用接口要好。

5.依赖倒置原则(DIP) (5. Dependency Inversion Principle (DIP))

High-level modules should not depend on low-level modules. Both should depend on abstactions.

高级模块不应依赖于低级模块。 两者都应取决于摘要。

Abstractions should not depend upon details. Details should depend upon abstractions.

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

什么是高级模块？ (What are the high-level modules?)

• High-level modules are part of an application that brings real value. They are the modules written to solve real problems and use cases.

  高级模块是带来真正价值的应用程序的一部分。 它们是为解决实际问题和用例而编写的模块。

• They are more abstract and map to the business domain (business logic);它们更加抽象，并映射到业务领域(业务逻辑)。
• They tell us what the software should do (not how, but what);他们告诉我们软件应该做什么(不是怎么做，而是做什么)；

High-level modules are telling about “what” software should do.

高级模块正在讲述“软件”应该做什么。

什么是低层模块？ (What are the low-level modules?)

• Contain implementation details that are required to execute the business policies;包含执行业务策略所需的实施细节；
• They are considered the “plumbing” or “internals” of an application;它们被视为应用程序的“管道”或“内部”；
• How the software should do various tasks;软件应如何执行各种任务；

High-level modules are telling about “how” software should do.

高级模块正在讲述软件应如何“做”。

例子： (Examples:)

• Logging (console, file)记录(控制台，文件)
• Data access (relation access, NoSQL access)数据访问(关系访问，NoSQL访问)
• Network communication (port, protocol)网络通讯(端口，协议)
• IOIO

什么是“抽象” (What is “Abstraction”)

• Something that is not concrete.一些不具体的东西。
• Something that you can not “new” up. In Java applications, we tend to model abstractions using interfaces and abstract classes.您无法“更新”的内容。 在Java应用程序中，我们倾向于使用接口和抽象类对抽象进行建模。

不使用DIP的示例： (Example of not using DIP:)

使用DIP的示例： (Example with using DIP:)

依赖注入 (Dependency injection)

A technique that allows the creation of dependent objects outside of a class and provides those objects to a class.

一种允许在类外部创建依赖对象并将这些对象提供给类的技术。

In our previous example, we still have coupling between our classes. We can solve it by using dependency injection:

在前面的示例中，我们的类之间仍然存在耦合。 我们可以使用依赖注入来解决它：

• one of the methods is using public setters (not a good one, because it can lead to uninitialized instances)一种方法是使用公共setter(不是一个好的方法，因为它可能导致未初始化的实例)
• a better approach is to initialize dependent in a constructor更好的方法是在构造函数中初始化依赖关系

Let's see how we can make our previous example better:

让我们看一下如何使前面的示例更好：

But what would be a solution to more complex examples like:

但是，如何解决更复杂的示例，例如：

It can be solved by using “Inversion of control”!

可以通过 “控制反转”解决 ！

控制反转(IoC) (Inversion of Control (IoC))

Inversion of Control is a design principle in which the control of object creation, configuration, and lifecycle is passed to a container of a framework.

控制反转是一种设计原则，其中将对象创建，配置和生命周期的控制传递给框架的容器。

• you don’t “new” up object anymore (they are created by IoC container);您不再“新建”对象(它们是由IoC容器创建的)；
• control of object creation is inverted (it’s not the programmer, but someone else who controls the object)对象创建的控制被颠倒(不是程序员，而是其他控制对象的人)
• it makes sense to use it for some objects in an application (services, data access, controllers), but for others (entities, value objects) is doesn’t;对于应用程序中的某些对象(服务，数据访问，控制器)使用它是有意义的，但对于其他实体(实体，值对象)则没有用；

IoC容器的好处 (IoC Container benefits)

• Makes it easy to switch between different implementations at runtime使在运行时在不同实现之间轻松切换
• Increases program modularity增加程序模块化
• Manages the lifecycle of objects and their configuration管理对象及其配置的生命周期

The DIP, DI and IoC are the most effective ways to eliminate code coupling and keep systems easy to maintain and evolve.

DIP，DI和IoC是消除代码耦合并使系统易于维护和发展的最有效方法。

一些使用IoC的框架 (Some frameworks that are using IoC)

Spring框架(Java) (Spring framework (Java))

AdonisJs(Node.js) (AdonisJs (Node.js))