SRP in Object-Oriented Design
SRP in Object-Oriented Design
This overview of the Single Responsibility Principle and SOLID design is a good base for novice developers and a good refresher for experts.
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
In object-oriented programming, there are five basic principles (SOLID) that, properly applied, make the difference between good and bad design. They're the difference between an application that is easy to maintain and one that is not. The difference between a good developer and a bad one. Today, I would like to concentrate on the first principle in object-oriented design (the Single Responsibility Principle) but first, let’s mention the five SOLID principles:
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Single Responsibility Principle
We’re going to start with the first one, the Single Responsibility Principle (SRP) that is defined by Robert C. Martin in his book “Agile Software Development, Principles, Patterns, and Practices”. The principle is actually a very simple concept to explain, but it can be difficult to implement. As its name suggests, it implies that a class or module must have a unique responsibility.
Within the context of the Single Responsibility Principle, responsibility is defined as a reason to change. That is why I consider the phrase of Robert C. Martin as a perfect definition of the Single Responsibility Principle:
“A class should have only one reason to change.”
By following the Single Responsibility Principle, you make sure that your class or module has high cohesion, which means that your class does not do more than it should. In short, it should have one unique reason to change. If, on the contrary, you build a class with more than one responsibility, you’re engaging these responsibilities. This leads to a design that is fragile and difficult to maintain, with all that that entails.
In this simple example, you can see a rectangle class that has two methods; Area () and Draw ().
- Area () has the responsibility to return the area of a rectangle
- Draw () has the responsibility to draw the rectangle itself
In this design, it can be seen that, if there are changes in the GUI, we must modify the Rectangle class, then we are obliged to test the other application that attacks the same class again. The solution to this problem is to divide the class in two so that each class has a unique responsibility. One will be responsible for calculating and another one for painting:
It’s important to keep in mind that this principle leads to many other nuances and concepts, and not only those that fall within SOLID, but others that should be known and able to apply to get an application with a solid design.
Published at DZone with permission of Oscar Galindo . See the original article here.
Opinions expressed by DZone contributors are their own.