No matter where you turn in the blogosphere, chances are you will eventually come across a post on the SOLID principles of OOD. As such, I quite often refer to the principles in discussions with other developers as if it were common knowledge. Quite often, however, I am asked to elaborate on these principles.
What is SOLID?
SOLID is an acronym for a set of principles of object oriented class design. It stands for:
- Single Responsibility Principle (SRP)
- Open Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
What is so good about them?
These principles combined, help to manage code dependencies by guiding the developer to write cleaner, well structured code to avoid OO anti-patterns and spaghetti coding. Adhering to these principles results in maintainable, flexible, robust and reusable code.
Breaking down the principles:
The Single Responsibility Principle states:
“A class should have one, and only one, reason to change” OR “There should never be more than one reason for a class to change”
A class should have one responsibility, and one responsibility only. One way of identifying whether or not you have violated this principle is by describing to yourself out aloud what the class does. If you hear the word “and” in there, chances are you have violated this principle. For example, if you designed a class that calculates a list of mathematical equations and emails the results to a recipient, you would have violated this principle. The class has two reasons to change (or responsibilities).
If the customer decides he no longer wants to receive the information via email, instead sending an SMS over the mobile network, then there is a reason to change. If the customer decides they want to change the way the equations are calculated, there is another reason to change. Perhaps the most extreme anti-pattern to this principle is the God object anti-pattern whereby a single class does almost everything imaginable in the system.
The SRP can be related with cohesion. A class that conforms to the SRP will be highly cohesive, as each method in the class will be closely related to its sole purpose. A class that does too many things is likely to have low cohesion.
The Open Closed Principle states:
“You should be able to extend a classes behaviour, without modifying it” OR “Software entities should be open for extension, but closed for modification”
At a glance, the principle may seem contradictory at first. How do you “extend” behaviour without modifying code? Quite easily, actually. Inheritance after all, is one of the fundamental designs of object oriented languages. As Martin puts is, abstraction is key. Inherit from an abstract class, mark methods as virtual, allow your class to be extended by it’s subclasses.
However, while it may seem the principle heavily promotes inheritance, it is always good to remember that it is best to “favour composition over inheritance”. It is also important to remember not to violate the Liskov Substitution Principle – as we will see later on.
In the next post we will look at the remaining principles of SOLID OOD.