SOLID Principles, The “S” part

Designing a software could be challenging and tricky to do, but as Isaac Newton said, If I have seen further it is by standing on the shoulders of Giants

If I have seen further it is by standing on the shoulders of Giants

In this case, the giant whose shoulder we stand on is Robert C. Martin who introduce SOLID principles in his paper. What is SOLID principles? SOLID principles are five core principles of Object Oriented design and programming. In this article we’re gonna talk about the “S” part of SOLID principle

S -> Single Responsibility Principle

The definition of this principle is: Every software component should have one and only one responsibility.

Every software component should have one and only one responsibility

This principle related closely with cohesion and coupling. What is cohesion? Cohesion describes how related the functions within a single module are. Low cohesion implies that a given module performs tasks which are not very related to each other and hence can create problems as the module becomes large. While coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are.

Cohesion describes how related the functions within a single module are, while coupling is the degree of interdependence between software modules

Let’s take a look at code example

In this code example getArea and getPerimeter are closely related since they deal with measurement of the square, so there’s high level of cohesion between these two methods. The draw and rotate are closely related since they deal with rendering the square to the screen.

So there’s high cohesion between getArea and getPerimeter, and between draw and rotate. But the level of cohesion between those four methods is low, since getArea isn’t closely related with draw.

So we’re gonna do some shuffling to increase the cohesion of the class

We’re just increasing cohesion between those methods as a class, by separating the concerns we can safely say that Square class responsible for measurements related of a square, while SquareUI responsible for rendering related of a square.

Reason to change

We have learned the principle of Every software component should have one and only one responsibility. There’s another modification of this principle that we can use as a tool. Every software component should have one and only one r̶e̶s̶p̶o̶n̶s̶i̶b̶i̶l̶i̶t̶y̶. reason to change.

Every software component should have one and only one r̶e̶s̶p̶o̶n̶s̶i̶b̶i̶l̶i̶t̶y̶. reason to change.

What does this principle means? Software is never dormant, it always keeps changing. Let’s take a look of this example class

We can jot down reason for student class to change, some of them might be:

1. Change in student data format
2. Change in database backend

There might be more, but we have to stop at some point. So, back to the principle Every software component should have one and only one reason to change. Why does this matters? Because more reason to change a component leads to more changes to a component itself, and changes could introduce new bugs. This will be a cost to retesting whole component before we release the modified version.

So how do we fix this? We can separate the class to look like this:

Therefore each class only have one reason to change, for Student class:

1. Change in student data format

For StudentRepository class:

1. Change in database backend

This way, the coupling between Student class and database backend is lowered too, Student class now doesn’t care the implementation on save/database backend as long as it is void and actually save student data to database of choice.

Well that’s for the “S” part of SOLID principle, next article we’re going to talk the “O” part of SOLID principle.

Thank you

Source: Udemy