I was recently thinking about Design Patterns, and how it was a big hype some time back. Don’t judge too fast, I am not very old. This is what I figured after reading many old articles on the internet. But nowadays, we, the young generation of Computer Engineers don’t talk much about Design Patterns. I guess it is also not wrong in a way that we have a takeaway option available. Let me elaborate a bit about what I mean by the Takeaway Option.
Previously our elders were forced to cook at home i.e. solve each problem on their own as there were not many solutions available for similar problems. As wise as they are, they decided to make some recipes for us i.e. why to reinvent the wheel if someone somewhere has already solved the problem, this is how the concept of design patterns came into the picture. But it was not enough for our lazy generation, we wanted the option to just place an order and take away the food. And hence came the concept of Frameworks. So all we had to do is to choose the right set of frameworks and make them work i.e. focus only on the business logic. Too easy right? But we don’t always have takeaways available, I think lockdown has taught us this very loud and clear😉 . Also, I think it is never harmful to understand how a framework works underneath to make it work more efficiently.
So let’s look a bit deeper into design patterns. But before that, we have to understand one more term –
SOLID Design Principles. They are pretty much “solid”, but this is not why we call them Solid. 😊
It is an abbreviation, which stands altogether for 5 these principles:
S — Single Responsibility Principle
O — Open/Closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle
Let’s start with the Single Responsibility Principle(SRP). It requests us for one simple thing, not to burden a poor class with more than one responsibility — do less but do it perfectly. In Simple words, a class should have one and only one reason to change.
A small Trick that might help you, to see if your class adheres to SRP:
I did my B.tech second-year technical internship in Ruby on Rails. During this time I came across a book called — Practical Object-Oriented Design in Ruby by Sandi Metz.
This book mentioned a little trick to know if your class abides by the principle of Single responsibility or not. Just ask yourself what your class does. If you have to use “and”, “or” to define the functionality, chances are that the class doesn’t adhere to the Single responsibility principle. ( A pretty good lesson from an impulsive decision of going with the internship just because I was pretty much impressed when I got to know that Twitter was built using Ruby language and Rails framework, and wanted to learn what was so special about this new language. You can understand how impressed I was if I tell you that the final project I created was named Twittee😁 , a complete copy of Twitter — but even I was merciful enough to give text content limit of more than 280 characters.)
When I read this “and/or trick”, the first thing that came to my mind was, why are we even sticking with the concept of classes and functions if they are going to be as thin as this and we are planning on dividing all functions into different classes. To get a bit more clarity, this article by Robert C. Martin (The good person who introduced these SOLID principles to us) came in handy. In the article, he states the same principle in different words:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
This Principle is all about people. Remember that the reasons for change are people. It is people who request changes. And hence different changes required by different people should be divided further. So let’s extend that ‘and/or trick’ a bit further and think about one more question — who is the program responsible to?
To understand this, let us take a classic Robert C. Martin example that he uses in his book and some of his articles.
Let’s say your company has an Employee management system, which looks like the following:
public class Employee {
public Money calculatePay(){
/** An algorithm than determines how much an employee should be paid depending upon his offer letter, working hours etc.*/
}public void save(){
/** Saves the employee data into company database. */
}public String reportHours(){
/** calculates the hours person spend working based on his swipe hours and timesheets.*/
}}
Of course, in reality, it will be a bit complex than this.
Now you must be thinking that of course all the three functionalities present here — calculatePay, save, and reportHours belong to employee and it makes sense if we keep them in the same class. This is the right time to ask the question to ourselves —
What does this class do?
It calculates the pay of an employee and calculates the reporting hours of an employee and saves its data to the company database. Three ‘ands’? Let’s ask further, who these functionalities report to? The pay calculation part seems to be the responsibility of the finance department of the organization, the hours reporting part the responsibility of the operations department and saving is the responsibility of the technical database department. Since we have 3 ‘ands’ and 3 responsibilities, its time to divide them into 3 different classes, and this is how SRP works.
Its advantages? Let’s count a few:
1. Easy Testing — when each class has a single responsibility and low coupling, it’s relatively easy to test. Especially in TDD (Test Driven Development) approach, it makes it fairly easy to write test cases according to the behavior of class and start development.
2. Free yourself from the maintenance mess — Believe me, the last thing you want to do in your project is to make a change in a class that affects other parts of the class and creates a cascading effect on the rest of the system. And I have seen programmers creating patches after patches on top of an old class, just to avoid changing the code written, which ends up being a bigger mess than we can handle.
Let’s look at one more interesting example by Uncle Bob.
Imagine you took your car to a mechanic in order to fix a broken electric window. He calls you the next day saying it’s all fixed. When you pick up your car, you find the window works fine; but the car won’t start. It’s not likely you will return to that mechanic because he’s clearly an idiot.
That’s how customers and managers feel when we break things they care about that they did not ask us to change. — and this is what SRP helps us avoid.
I think it’s enough knowledge transfer, for this article. Please go through my next article in the series on the Open-Closed Principle. Let’s do one thing before the next session, take it as an assignment, and come up with a practical implementation for the Single Responsibility Principle and do share it with me.
Happy Learning!
