SOLID Principles

SOLID¶

SOLID is the name of a methodology and an acronym for the five basic principles of designing software based on an object-oriented approach. Like the application of other architectural principles, applying SOLID helps maintain and upgrade code.

SRP

Single-responsibility principle.

The final version of SRP is formulated as "A module should be responsible for one and only one actor"; Robert C. Martin himself considered SRP somewhat difficult to understand, but in my opinion, things simplify quite a bit if we use the term "group of people" instead of "actors." It immediately becomes clear that an "actor" is not some interconnected classes or other program entities, but just people, users, for whose benefit the program is being developed. Accordingly, a class should be responsible for fulfilling the requests of only one group of people.

If we simplify the wording even further, we could even say that a class should be responsible for the interests of only one department. Therefore, if a class implements functionality needed by both the accounting department and the supply department, or for instance by both designers and engineers, such a class needs to be rewritten, divided into two.

OCP

Open–closed principle.

Classes should be closed for modification of their existing external properties (so that the calling code relying on these classes does not need to be updated), but at the same time open for extension and the addition of new methods and behaviors. In other words, when modifying existing methods of a class, the code can only be changed in such a way that the class's external behavior remains unchanged.

LSP

Liskov substitution principle.

A principle that declares rules for changing functionality during inheritance. Code using a variable of a base class should not notice any difference if a variable of a subclass is "slipped in." In other words, a subclass should not demand more from the calling code than the base class does and should not provide less capability to the calling code than the base class.

ISP

Interface segregation principle.

The implementation of an interface should not be concerned with unused methods. Following ISP, it is recommended to create minimalist interfaces, without "extra" methods, containing the minimal and necessary number of specific methods, all of which are required when creating an implementation. If an implementation of an interface does not use a certain method of the interface, it is better to create a new interface without that method.

Failure to follow the ISP principle will lead to having to adjust the specific implementations' code when the interface containing "extra" or "additional" methods is changed, even though the code does not need or use these methods.

DIP

Dependency inversion principle.

DIP, like the principle of Inversion of Control (IoC) in general, is one of the pillars of clean architecture. Top-level modules should not address lower-level modules directly; there should be an "interlayer" of abstractions (i.e., interfaces) between them.

Two important rules of DIP:
interfaces should not depend on specific implementations; on the contrary, implementations should depend on interfaces, i.e., you should first design interfaces and only then work on specific methods;
interfaces should be stable; implementations can change frequently, but it is preferable to adjust interfaces as rarely as possible.

Top page.

Go to RU version of this page.