SOLID Principles

12 February 2021

In this article we’ll learn SRP and why it’s important and what all issues you’ll face in the long run if you don’t follow SRP.

Creating a quality code in the development phase is undoubtedly the task of every developer who cares for the software app. Best practices aim to minimize code ambiguity, the coupling between classes, dividing roles, and specifying their relations. There are easy ways of enhancing the internal quality of the code.

Why we need S.O.L.I.D. Principles?

The code can become inflexible and more brittle when the developer builds software following a bad design. Bugs can arise from minor changes in the program. We should obey the SOLID principles.

It takes some time to learn, but it will increase code consistency and make you understand the most well-designed applications if you write code using these concepts.

What Do They Stand For?

• S – Single-responsibility principle
• O – Open-closed principle
• L – Liskov substitution principle
• I – Interface segregation principle
• D – Dependency Inversion Principle

Single Responsibility Principle (SRP):

A class should have one and only one reason to change.

In reality, this means two things:

• A class should only do one thing
• There is only one reason to change a certain class

Simple example of SRP:

Let’s say you’re building an app that generates Student report cards.

You created a class ReportCardGenerator in your app. It fetches data for the report card, formats it, and Mail the report card in PDF Format.

After a while, you decide to change the way the report card looks. It needs some new font, some different colors, and an extra data table.

You also decide to instead send a report card in PDF, you’ll now send it in JPEG images.

Now, you remember the single responsibility principle, and you realize your mistake! Instead of one responsibility, your class has three:

• Fetch data for the report card.
• Create the report card formatting.
• Mail the report.

So what actually Single Responsibility means?

It’s important to understand something here.

So the single responsibility is defined as “one reason to change”, not “one responsibility”. You could say that “generating reports card” is one responsibility, and you’d be right. Why would you break it up in multiple classes, then?

The important difference is “reason to change”. So we distribute these responsibility to different classes and these three classes now each have one reason to change: change the data fetching, change the report formatting, and mailing it.

Now it is easier to maintain and debug than 1 class with 3 reasons to change.

Example:

Here User manager class has 3 reasons to change so it’s definitely not following the SRP.

1. First reason to change for this class is the requestData() method. What if in future we need to use or change some 3rd party library to call the API.
2. Second reason to change for this class is the convertJSONToModel(with: ) method. What if in future we need to use or change some 3rd party library to JSON to model.
3. Third reason to change for this class is the saveDataInDatabase(with: ) method. What if in future we decided to use some other database?

This type of class or object of this class is known as God Object or God Class which does too many things and knows too much.

So what’s the main problem with this class?

UserManager class has a lot of responsibility as listed above.

So how can we solve this problem?

We need to create separate classes for each responsibility, like this:

Single Responsibility Principle helps you keep your class and code as clean as possible. Now we can also create a unit test for each responsibility in the first example, it’s hard to test.

In Next article we’ll look into the open-close and Liskov substitution principle.

🔊 Listen