Key ideas about Separation of Concerns Software Design Principle
Separation of concerns(SOC) is one of the core software design principle that is widely adhered to. The main idea of this principle is to isolate the software application into separate sections. Each section should address a distinct concern that has little overlap with other sections.
Separation of concerns can be applied on mainly 2 levels — architectural level and programming level.
Architectural level
An application can be separated into various layers. For example, a web application can be separated into the following layers:
· User Interface
· Data access/Model
· Business Logic
User interface’s role is to render the view to the users. Model will store and retrieve data from the database. Business logic will be responsible for facilitating the flow of data and handling events. Clearly, each layer is in charge of only one concern and the concerns do not overlap much between each other.
Programming level
On a programming level, the services can be separated at different levels. Let’s take an example of a simple online shopping site.
SOC can be applied on the component level. The following is a simplified component diagram of an online shopping site:
Broadly, we can categories the services into 5 components. Each component will have a distinct role. For example, Payments component will only be responsible for processing the payments; it will not be in charge of handling the addition and deletion of orders as that is the role of the Orders component.
The components can be further divide according to the specific features and functionalities. For example, Payments component can have a Payment class.
The class shown above is an example that violates the SOC principle. Payment should only handle the processing of payments. It should not be responsible for any functions that modifies the order. Thus, deleteOrder() method should be extracted and be placed in the Order class like the following:
Separation of concerns is equally critical on the programming level as it is necessary to ensure that the application is scalable and flexible to changes. Separations of concerns principle strives to achieve this by promoting modularity such that new features can be added or modified without having a drastic impact on the other modules.
Benefits:
· Manage complexity and increases maintainability of the module
· Enhance cohesion and reduce coupling between modules
· Enable scalable program that is open to extension
· Allow easy reuse of modules and functionalities
· Reduces fragility of modules
For example, let’s assume there is a new feature to be added to a project, if SOC principle is adhered to, the programmer will only have to change the relevant code that are directly associated with the new feature. As each functionality is properly contained within a module, a change in one module would not lead to a domino effect where it causes multiple impacts on the unrelated modules.
In addition, as the modularity of the components are properly maintained, it is also flexible to any implementation changes. If the implementation or database needs to be replaced, the programmer would not need to modify the rest of the program.
An example where this principle is used in real-life would be the Model-View-Controller (MVC) architectural pattern.
As we can see, View will be solely responsible for displaying the user interface and handling interactions with the users. Controller will contain only the control logic and Model will be in charge of defining the data structure and updating the database. The concerns are separated as such because changing the user interface should not affect neither the business logic nor the data storage and vice versa. Hence, they should be categories into different concerns.
Conclusion
Separation of concerns is a fundamental software design principle on which many other design principles are dependent on. It helps prevent high coupling between modules and enhances the cohesion of each module. Hence, it is a very crucial principle to follow.
