Separation of Concerns
Edsger W. Dijkstra is credited with coining Separation of Concerns in his 1974 paper titled, “On the role of scientific thought.” In this paper he states:
Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have calledthe separation of concerns, which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean byfocusing one's attention upon some aspect: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.
In order to master complexity, one has to deal with one important issue (or concern) at a time. Dijkstra, 1976
What is a Concern?
Concerns is a way of organizing requirements. You can think of it as a particular issue of focus. I like to use the term dimension instead of concern. Because there is a lot of confusion about the term concern in the current literature.
The principle states that software should be decomposed in such a way that different aspects of the problem are addressed in separate parts of the software system. This principle should drive the identification of the decomposition of a problem. The decomposition into parts must overlap in functionality as little as possible. It promotes the separation of different interests in a problem, solving them separately without requiring detailed knowledge of the other parts, and finally combining them into one result. It also serves to structure the functionality of programs.
Impact of Changes
- Changes to one part of the program do not impact other parts of the program.
- The worst case scenario is when changes are required, they are localized to a small number of elements.
- If the requirements change, then the part of the program that has to be changed is obvious.
- It is easier to trace concerns, expressed as a requirement to the program that implement these concerns.
- You can focus on one element without regard for the other elements in the program.
- You can understand each part of the program by knowing its concern, without the need to understand other elements.
- Refactoring source code within limited scopes becomes possible.
- Sections of code can be written independently.
- It encourages decoupling.
- It results in modular programs.
Applying the Principle
Programming language constructs such as methods and classes are the mechanism to organize and structure the core concerns of a system. We should organize software so that each element in the program (class, method etc.) does one thing and one thing only.
How do you find the areas of interest in the code? The principle of orthogonality in software can be used to find the answer. It is discussed in the article on Orthogonality Software.
Ace the Technical Interview
- Easily find the gaps in your knowledge
- Get customized lessons based on where you are
- Take consistent action everyday
- Builtin accountability to keep you on track
- You will solve bigger problems over time
- Get the job of your dreams
Take the 30 Day Coding Skills Challenge
Gain confidence to attend the interview