You may have heard of SOLID. The SOLID design principles are well known design principles in object-oriented software design. The principles were first promoted by Robert C. Martin (also known as Uncle Bob). Later Michael Feathers introduced the SOLID acronym.
What is SOLID
SOLID is a mnemonic acronym for the following five principles:
- Single Responsibility principle: All classes should only have one responsibility.
- Open/Closed principle: Reusable software entities (classes, modules, etc.) should be open for extension, but closed for modification.
- Liskov Substitution principle: Derived classes must be usable through the base class interface without the user knowing the difference.
- Interface Segregation principle: The dependency of one class to another should depend on the smallest possible interface.
- Dependency Inversion principle: Details should depend upon abstractions. Abstractions should not depend upon details.
Each principle can stand on its own. And each principle will improve the robustness and maintainability of object-oriented code. But they also work together. If we apply all the principles, we make the implementation of each one easier and more effective.
In this short set of tips, we’ll look at each of the five SOLID design principles in turn. We’ll see how to use them to create object oriented software that is easy to maintain and extend. They also make it easy for us to refactor code and avoid code smells.
Let’s look at the first and most important principle: the Single Responsibility principle.
Single Responsibility Principle (SRP)
“A class should have one, and only one, reason to change”. All classes should only have one responsibility.
All software components should only have one responsibility. This applies to both classes and services. It is easier to understand, design, develop, maintain and debug a component that does one thing, than a component that does everything. A single responsibility also avoids any unnecessary coupling between responsibilities. This reduces the need to change the class in the future. Each future change is less complex because it affects fewer dependent classes.
Software requirements have a nasty habit of changing over time. Each change in requirement triggers a change in the responsibility of at least one class. The more responsibilities a class has, the more often it needs to be changed.
Here’s an example. Think of a class that opens a connection to a database, extracts some data from a table, and displays that data. This class has too many responsibilities. This means there are too many reasons that could force it to change. It must change if we move to a new database or if we move from a relational database to an ORM (object relational mapping). It must change if we modify the structure of the table. It must change if we display the data in a different format. This class violates the Single Responsibility principle by doing too much.
It would be a far better design to create a number of classes, each having a single responsibility. There should be a separate class (or combination of classes) interacting with the database. There should be another class that processes the extracted data. There should a class that displays the processed data; probably even a number of display-oriented classes, each responsible for interacting a different display type, e.g. an HTML page, a Windows display, an Android application, etc.
The Single Responsibility principle is arguably the most important principle. Violating the SRP results in code that is unstable and difficult to maintain.
What’s next?
Next week we’ll look at the second principle: the Open-Closed principle.
As always, please share your comments and questions.