Dec 31, 2021
Separation of Concerns
Core Spirit
These days the term, Separation of Concerns, keeps popping up from my studies, such as Rust programming, REST tutorial, or even in my daily work. It is too frequently-mentioned in the articles so I decided to explain such an important concept in the software engineering.
In design rules, we attempt to separate a set of information into different groups, within which information associates instead of depending on those in other groups.
The term, Concerns, indicates a set of information we would like to separate in a context. In programming, we apply encapsulation to avoid private members from being revealed to clients; make use of polymorphism to refer to derived instances of the same type. The mixed use of both concepts in OOP helps us separate functionalities into modules of single responsibility. Therefore we are able to scale programs and interconnect modules based on interfaces defined rather than focus on solving dependency issues.
For example, in design pattern we advocate the rule: program to interface. This is a real application of the the concept in design work because as our program scales as requirements vary, it gets necessary to shrink code size by making modules loosely-coupled that makes a codebase maintainable, reusable and stable.
Is it abstract to you? Well, it is the definition I experienced from what I had done in my past work and I believe it would evolve as time goes by. In fact, the rule could be adopted not only in the software engineering but also in many other fields in our lives.
REST Constraint: Uniform Interface
In restful API design, we try to define an uniform interface that focuses on resource manipulation in order to achieve a pure Client-Server model. Therefore we are able to decouple one side from the other and both evolve independently as they communicate by the pre-defined interface as below:
GET /api/order/1
POST /api/order
PUT /api/order
DELETE /api/order
In short, restful APIs other than than conventional action-based APIs aims to indicate which resource it is going to manipulate and leaves processing logics to server-side programming. So developers can scale intermediaries by formulating uniform interfaces among systems without caring about what sorts of programming languages, platforms dependencies, etc.
This is a great example of Separation of Concerns that works: Scale systems by defining coherent interfaces among them and realize loosely-coupling implementation.
Life Example: Adapter
Another obvious example is an voltage adapter. When we travel outside, we need to solve the issue that the voltage criterium in our country might be different from others so we often ask for help with an adapter.
As you see, an user need not care about what kinds of holes it plugs in but knows the output voltage would be the same as he uses in his country when an adapter is applied. That is what an adapter does for us: transform input voltage into required output voltage.
Therefore, an adapter successfully separates a client’s use habit from input source by implementing the middle transformation logics.
Coach’s Murmur
In fact, there is actually an Adapter Pattern in software design methods that helps with integration when it comes across adapting one interface to the other. We are going to discuss the topic in the following articles.
Making good use of the idea: Separation of Concerns, could assist you scale applications very quickly and make them easily-maintainable as well. After all, nobody would like to take over highly-coupled modules that are hard to refactor. An experienced engineer would push the realization of the concept to the extreme.
—
If you acknowledge the value I share with you, do as below:
1. clap the article
2. subscribe me for latest contents
3. follow me on other platforms for further information
- IG: @ur_agile_coach
- Podcast (Chinese): Agile Rocket
- Youtube: Your Agile Coach
- LinkedIn: Tsung-Hsiang Wu
If you need consultancy or other forms of collaboration, send a mail to: urscrummaster@gmail.com
