S.O.L.I.D principles: what are they and why projects should use them
Creating a quality code throughout the development phase is undoubtedly the mission of any developer who cares about your software product. Best practices tend to reduce code complexity, the coupling between classes, separating responsibilities, and defining their relations. These are simple ways to improve code internal quality.
And what are these fundamental principles that help us to keep the code organized without code-smells and ̶s̶h̶a̶r̶e̶a̶b̶l̶e̶ ̶o̶n̶ ̶G̶i̶t̶h̶u̶b̶/̶B̶i̶t̶b̶u̶c̶k̶e̶t̶ ̶w̶i̶t̶h̶o̶u̶t̶ ̶f̶e̶a̶r̶ ̶o̶f̶ ̶b̶e̶i̶n̶g̶ ̶j̶u̶d̶g̶e̶d̶ clean? They are the S.O.L.I.D principles, and we’ll talk about them in the next sections.
What is S.O.L.I.D?
Concepts and principles…
S.O.L.I.D is an acronym that represents five principles of object-oriented programming and code design. It was theorized by our beloved Uncle Bob (Robert C. Martin) by the year 2000. The author Michael Feathers was responsible for creating the acronym:
[S]ingle Responsibility Principle
[L]iskov Substitution Principle
[I]nterface Segregation Principle
[D]ependency Inversion Principle
We’ll talk in detail about these five principles in the sections below.
Single Responsibility Principle (SRP)
A class should have one, and only one, reason to change.
This first principle says that “a class must have only one reason to change,” that is, it must have a single responsibility. This principle deals specifically with cohesion. Cohesion is defined as the functional affinity of a module’s elements. It refers to the relationship that the members of this module have if they have a more direct and essential relationship. That way, the more clearly defined your class does, the more cohesive it is.
See the example of the
Employee class. It contains two methods:
calculatesSalary(), which calculates the employee’s salary, with a tax discount, and
save() which is the persistence control method, to open a connection to the database and saves an employee in the database.
Notice that this class does many things that aren’t necessarily tasks of it. For example, in evolving this system, if we want to persist another entity in the “Company” model, such as a
Order, we will have to keep replicating the
save() code snippet.
Suppose we want to calculate the salary of other employees from other positions, with different tax discounts. In that case, we should create different calculation methods. All these solutions, of course, aren’t feasible.
However, how to apply the SRP minimally in this scenario? We can break these responsibilities of the
Employee class into more classes:
ConnectionDAO (to manage the database connections),
EmployeeDAO (to implement all employee-specific persistence methods), the
Position enum (to save calculation rules per position),
CalculationRule (which is an interface that has the calculation method), and for each tax discount scenario, we can define a class to save this information.
Lastly, we can change the
Employee class behavior so that every employee has a
Position. In the
calculatesSalary() method, the calculation rule, which is encapsulated in the position, can be accessed without any damage.
With this refactoring, the
Employee class has a single responsibility. When a class has only one responsibility, they tend to be more reusable, simpler, and propagate fewer system changes. Commonly, we use FACADE and DAO patterns to avoid architecture with strong coupling and low cohesion.
Open/Closed Principle (OCP)
You should be able to extend a classes behavior, without modifying it.
It says that “software entities (classes, modules, functions, etc.) must be opened for an extension, but closed for modification.” In detail, it says that we can extend the behavior of a class, when necessary, through inheritance, interface, and composition. Still, we cannot allow the opening of this class to make minor modifications.
To illustrate this principle’s understanding, let’s observe the
PriceCalculator class, which belongs to a fictitious e-commerce system.
This class has a
calculates() method which checks the discount and freight rules from the product payment method. Suppose the product is purchased by cash or single credit card payment. In that case, you have a specific discount in the
If the product is purchased on a credit card with installments, it has a particular discount on the
PriceTablePaymentInInstallments class. Besides, the discount rules also vary according to the product’s price. And in freight, the value also varies by geographical region.
The problem with this implementation is the complexity. The more rules you create, the maintenance of this class will be unfeasible. Also, the coupling of the
PriceCalculator class will increase because it will increasingly depend on more classes.
Now, how to use OCP to solve this problem? Simple! Let’s create the
PriceTable interface to represent the abstraction
discountCalculation(), regardless of the product payment method. Also, let’s create the
freightCalculation() abstraction in the
After these changes, the
PriceTablePaymentInInstallments classes will begin to implement the
PriceTable interface, and the
Freight class starts to implement the
With this, we could wipe the
PriceTable class, no longer need to know the various tables’ behavior. That is, we will CLOSE the
PriceTable classes for changes. In this case, if other rules arise to be used in the
PriceCalculator, we are implementing new classes to represent them and receiving them by the constructor.
In summary, this principle talks about maintaining useful abstractions. Besides, when using the STRATEGY pattern, we are obeying the OCP.
Liskov Substitution Principle (LSP)
Derived classes must be substitutable for their base classes.
It says, “subtypes should be replaceable by their base types,” pondering the care to use inheritance in your software project. Despite inheritance is a powerful mechanism, it must be used contextualized and moderating, avoiding classes being extended only by having something in common.
This principle was described by the researcher Barbara Liskov in her 1988 paper, which explains that we need to think about class’s preconditions and postconditions before choosing to inherit.
To be clearer, let’s observe the example of the
CommonBankAccount represents any bank account within our simplified context. It has the methods
CheckingAccount is identical to the
CommonBankAccount class, except for the
income() method. A checking account has no income; it is only for receiving a salary.
That way, we can solve this problem by extending the
CommonBankAccount class, as shown above, and making the
income() method throws an exception, right?
As expressed by our dear boss Michael Scott, this is not a good idea! If we were to try to access the
income() method of all bank accounts in a loop, for example, and one of them is a
CheckingAccount. Our application doesn’t work because, for any checking account, an exception is thrown.
In this scenario, we should refactor and use composition. Let’s create an
AccountManager class, and this class will control the account’s financial movements.
CheckingAccount classes now have an
AccountManager, removing the unnecessary parent-child relationship between them.
Notice that in the refactored version of the
CheckingAccount class, we don’t need to implement the
income() method. We only use the manager in the behaviors that the class has. Uncle Bob explains that LSP is the enabling principle of the Open/Closed Principle since the possibility of substituting subtypes allows a module to be extensible without modifications.
Interface Segregation Principle (ISP)
Make fine grained interfaces that are client specific.
It says, “many specific interfaces are better than a general interface.” This principle deals with cohesion in interfaces, the construction of lean modules, and few behaviors. Interfaces that have many behaviors are challenging to maintain and evolve. So, it should be avoided.
For a better understanding, let’s go back to the
Employee example and turn this class into an abstract class, with two other abstract methods:
Then, in our example, we have two positions, which will extend this class
Seller and the
Employee class has a behavior that doesn’t make sense for the
getCommission(). The developer’s salary is calculated based on hours worked and contracted, having no relation to total sales in a period.
Hence, how to solve this problem? We are going to refactoring the code to break these behaviors into two interfaces:
Employee starts to implement the
Developer class doesn’t even need to exist since the
Developer is an
Employee with a
Conventional payment regime. In the same way, the
Seller class starts to implement the
Commissionable interface, with
getCommission() method, which is specific to this type of
The ISP alerts us to the “fat” classes, which cause unusual and damaging couplings to business rules. We have to be careful, and this tip is good for the other principles: do not overdo it! Thoroughly check for cases where segregation is necessary, preventing hundreds of different interfaces from being created improperly.
Dependency Inversion Principle (DIP)
Depend on abstractions, not on concretions.
It says that we must “depend on abstractions and not on concrete classes.” Uncle Bob breaks the definition of this principle into two sub-items:
- “High-level modules should not depend on low-level modules. Both should depend on abstractions.”
- “Abstractions should not depend on details. Details should depend on abstractions.”
The option of abstractions is because they vary less and make it easier to change behaviors and future code evolutions.
When we speak of OCP, we also saw an example of DIP but don’t talk exclusively. When we do the
PriceCalculator class’s refactoring, instead of having direct dependence of
PriceTablePaymentInInstallments, we inverted the relationship on two interfaces:
Freight. Thus, we continue to evolve and maintain only concrete classes.
The idea of applying the principles in software projects is to take advantage of the benefits of using the object-oriented paradigm correctly. Furthermore, we can avoid problems such as lack of code standardization, duplication (remember “Do not repeat yourself”?), and lack of maintenance.
You can follow all these tips to have an easy code to maintain, test, reuse, extend, and evolve, without a doubt. A piece of important information: besides reading the main bibliographies on the subject, such as the books Agile Principles, Patterns, and Practices in C# and Principles of Ood, you should start practicing on personal, small, and more straightforward projects.
Besides, you can start by making changes in specific classes, avoiding code smells. The faster you begin to practice, and the more mature your way of thinking will be when faced with more complex development situations.
Full examples that have been used in the article can be found in the artigo-solid-medium project on Github.
I hope you enjoyed the post!
- Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin, 2011)
- Agile Principles, Patterns, and Practices in C# (Robert C. Martin; Micah Martin, 2011)
- Alura — Cursos Online de Tecnologia — Design Patterns Java I: Boas práticas de programação
- Alura — Cursos Online de Tecnologia — Design Patterns Java II: Boas práticas de programação
- Alura — Cursos Online de Tecnologia — SOLID com Java: Orientação a Objetos com Java