The Single Responsibility principle and separation of concerns principle are two well known design principles in object oriented programming. Today, we will take a closer look into each of them.
Contents
The Background
An object in object oriented(OO) programming represents a known(tangible / intangible) entity. In OO programming you use an object to get some work done in the program. So an object offers some functionality. Objects can be seen as black box that are known by what the can do for you rather than what they contain. We should not know or bother about the internal data structure that it holds. We should know that it provides certain functionality through its methods and the method needs certain types of data. Objects also can be initialized using certain data or other objects. When you call the method and provide some data if it performs something that it promises to do. You should not know/bother how it does that work. This is what encapsulation is about in the object oriented programming paradigm.
What also needs to be taken care of is, the interface using which the outer world will interact with the object. The interface should be properly defined, meaning the signature of the methods and what they return should be formally agreed. This is done using interfaces. That is why we say object oriented programming promotes data abstraction and hiding.
What is the Single Responsibility (SRP) Principle ?
Object oriented design principle starts from here. The principle says, an object should take responsibility to do a certain task. This principle is named as the "Single Responsibility" principle. Wikipedia has a good clear definition . It does not mean an object should do only one thing rather it says one thing and the same thing should be done by only objects of one class. The job of an object is to provide a solution for one problem. When there are closely related tasks and functionalities those can be bundled under one object’s responsibility. As an example, an object should not have multiple tools to open bottles and hammer a nail. These are separate tasks. But the object can have different types of openers needed to open different bottles. We can also look at this from a different angle. It is said that when we follow SRP an object will have only one “reason for change”. If we see the above example it will have two reasons for change, when we need to enhance or modify something related to opening a bottle and also need to enhance or modify something related to hammering a nail.
Advantages of Single Responsibility Principle
When we follow this principle it also complements the high cohesion and low coupling principle. It makes life easy for the programmer when it comes to maintainability and reusability. If the responsibility is scattered across different classes then when we need to enhance or fix a bug we need to touch several places which increases changes of regression. We can also easily reuse the functionality when only one class is taking care of the functionality.
What is the Separation of Concerns Principle ?
The "separation of concerns" principle tells us that we should separate the concerns (here hammering a nail and opening a bottle). The single responsibility principle says that only one class should be responsible to do the same task. To open a bottle we should always use an object of one class. It can have multiple interfaces that can be used to open different types of bottles. The separation of concerns principle says that we should always make clear groups of classes or behaviours that address a particular concern about how a job will be done. And separate the different groups as much as possible. This principle can be used at different levels in software engineering. Starting from Class we can also apply it for packages and modules. You can check out the definition given by Wikipedia as well. When we design large software systems and products we can use this principle to create layers and modules. In cloud native architecture we can apply this principle to create separate micro services.
Advantages of Separation of Concerns Principle
The separation of concerns promote abstraction in programming language and also make it possible that a class or module can be replaced by another in future without being able to change everywhere in the code. There will be some changes needed but that will have less side effects if any. Basically it provides more freedom to develop each separate concern and provides clients with which one to choose from a range of options. For example, if we separate out the string manipulation tasks in a separate utility, we can decide independently how those utilities will internally work. In future when there are several such similar utilities available that do string manipulation we can opt for another utility over an existing one being used.
In summary, we can say Single Responsibility and Separation of Concerns object oriented design principles are the two important design principles that define the base of many other design principles, patterns, practices and guidelines.