The key concept for Software Engineering and the basis of Object Oriented Programming, Aspect Oriented Programming, Subject Oriented Programming and Hyper Space programming.
The term seems to have been coined by Ew Dijkstra - [Source:On the role of scientific thought, EWD 477, 30th August 1974, Neuen, The Netherlands] - the relevant passage:
It is what I sometimes have called “the separation of concerns”
Download a PDF:
Asymmetrically vs. Symmetrically Organized Paradigms for Software Composition
Parnas' On Decomposing Systems doesn't use the term, but definitely has the idea: "Every module in the second decomposition is characterized by its knowledge of a design decision which it hides from all others."
I believe the first reference is actually in Polya's classic book How To Solve It. -- Anthony Lauder
Which is what the phrase is meant to deal with, Dealing With Concerns. Anyone can make lists of Concerns for someone else to solve. But Concerns should be localized. One should ask - is this something I should be concerned about, and can I do anything to deal with the concern. One in action dealing with a concern is doing something to reduce the number of concerns involved in a local situation or scene. It has been transformed from a concern to a concerted effort.
The problem is that "concerns" are relative. I belong in the Everything Is Relative camp on this one. There is rarely perfect grouping and perfect separation. The degree that any two things are related is a continuous scale, and often changes over time. Thus, either we come up with a Useful Lie, or use some kind of ad-hoc querying technique to bring together what we want to look at when we want to look at it (see Code Avoidance).
If one employs a "Useful Lie", or practices an avoidance, what was a concern, becomes irrelevant and will no longer impinge on the "Concerns" in one's Personal Queue. It then has been classified as "Let George Do It", or "It's not my job".
I am not quite sure what you mean. Can you provide an example? It is not necessarily a matter of responsibility, but simply that a given thing may participate in multiple different groupings or relationships over time or per user/coder.
I believe that Management Of Concerns is a more realistic goal because pure separation itself is not practical in many domains. -top
Separation Of Concerns doesn't need to be "pure" to be useful. Certain concerns - security, safety, performance, persistence & disruption, modularity, portability, error-handling, logging, etc. - tend to be Cross Cutting Concerns no matter how you try to cut them. Separation Of Concerns on the smallish scale - i.e. splitting a Big Ball Of Mud of specific domain concerns {A,B,C,D} such that they can be encoded separately in smaller groups {A,B} and {C,D} - is both realistic and useful for Management Of Concerns. I'd assert that General Purpose Programming Language's primary task is simplified management of the many Cross Cutting Concerns. -Anonymous Donor
Moved discussion to Table Oriented Code Management Discussion.
If one is dealing with a problem, it is important to decompose the problem into solvable fragments. In doing so, the relationships between what needs to be done and when it needs to be done can be discovered and plans to deal with the problem fragments can be assigned to, or if one does not have the power position to assign, identified as belonging to, Solution Spaces.
The last "or" clause seems to be missing a verb, or else I am having trouble parsing this. Otherwise I agree that we have to draw lines in order to divide up work. A Useful Lie. However, no line is perfect and is always a compromise. For example, to multinational corporations; countries, provinces, etc. are a hinderance. The grouping "country" is orthogonal to "corporation" more or less.
Separation and Yagni
Here is an example of where Separation Of Concerns may violate Yag Ni.
Suppose we have a GUI system and we are defining an On-Click button event:
define button_7_onClick(...) { executeSql("UPDATE myTable SET x = x + 1 WHERE id=4"); }
Many pro-separation documents recommend putting all SQL together in one code unit dedicated to SQL. Thus, it allegedly should be:
define button_7_onClick(...) { incrementId4(); } .... module SQLstuff { // a different file .... function incrementId4() { executeSql("UPDATE myTable SET x = x + 1 WHERE id=4"); } }
This creates more code and more jumping around to edit and view. If "incrementId4" is referenced once and only once, then we have wasted code, bloated code, and violated Yag Ni. I agree that if that something is likely to be shared that perhaps it should be put into a shared area (but perhaps not by SQL-ness). But often such is not the case. A given set of actions is done in just one place.
(I thought I included an example like this already. Either it was erased or I put it in a similar topic.)
-- top
-- seperating GUI and SQL code seems like a very good idea! Single Responsibility Principle and all that. We stopped thinking the being called more than once was the only reason for creating a procedure some time in the 1980s. Have you read Structured Design by Constantine and Yourdon? You do claim to be the Procedural programmer? Have you read any modern book on Refactoring? Nick Keighley
If you gained bunches of great knowledge from such books then use it to explain WHY, rather than "do X because Mr. Y says so". Software Engineering Is Art Of Compromise, one is balancing multiple factors when selecting among trade-offs. I respect people who know and can explain the trade-offs. I may disagree with their weightings at times, such as disagreements about how human Wet Ware reacts to given designs, but I hope one at least demonstrates they've done their "trade-off homework". And I'm not saying it's always better to keep together or separate SQL. The best answer often depends shop practices, shop skill divisions, application type etc. --top
You have illustrated a case where Premature Optimization trumps Separation Of Concerns. This doesn't weaken the validity of this concept, but it must be prioritized appropriately.
All else being equal, I agree that the separation is a good thing. However, there are at least 2 other counter-factors that we need help weighing against it:
Other orthogonal grouping/separation factor candidates
Note if there are too many competing factors, then perhaps no division is the way to go, or else meta-tizing it so that factors can be dynamically/virtually isolated as needed (smells like tables, eh? :-)
Other factors (such as Premature Optimization)
--top
Another area where a conflict seems to often appear is validation and processing. For example, it may take a lot of code to parse something for validation. Sometimes one can also use that parsed info to reformat the information. It seems a violation of Once And Only Once to copy the validation parsing code for formatting also. One could make a shared function or utility to do the parsing, but then we are not only performing the same parse action twice, slowing performance, but also clogging up the code with very specific, rarely used functions or utilities. Kiss Principle seems to dictate intermixing validation and formatting. (A Duplication Refactoring Threshold of 2 is a bit low in my opinion unless the code is long.)
Two concerns that I would like to see separated in programming are data and Real Information. Data has to do with what a database is designed to do best, handle large amounts of very precise content in little pieces. The information section would focus on providing a representation in code of the way the user thinks (in data structures themselves, not in the UI). There would be a translation interface between the data and information sections, and representation engine for interacting with the user. --Jon Grover
That's an interesting notion. Can you provide a simple, concrete illustration that exemplifies the distinction between data and Real Information? In particular, can you clearly illustrate how data differs from information? There are some relevant -- but unanswered -- questions on the Real Information page, too.
Typical computing-space concerns include:
Business logic
Security
Error/exception-handling
Debugging/tracing
I/O
Database (arguably more than "I/O", see Databases Are More Than Just Storage)
Files
Networking
UI
These are not necessarily mutually-exclusive.
Separation Of Concerns does not imply "disconnected". Database and Files are necessarily connected, but that doesn't mean they can't be separated. I'm separate from you, but we communicate.
Related:
See original on c2.com 