Separation Of Concerns
Separation Of ConcernsThe key concept for SoftwareEngineering and the basis of ObjectOrientedProgramming, AspectOrientedProgramming, SubjectOrientedProgramming and HyperSpace programming.
The term seems to have been coined by EwDijkstra - [Source:On the role of scientific thought, EWD 477, 30th August 1974, Neuen, The Netherlands] - the relevant passage:
Parnas' OnDecomposingSystems 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 HowToSolveIt. -- AnthonyLauder
Which is what the phrase is meant to deal with, DealingWithConcerns?. 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 EverythingIsRelative 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 UsefulLie, 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 CodeAvoidance).
If one employs a "UsefulLie", or practices an avoidance, what was a concern, becomes irrelevant and will no longer impinge on the "Concerns" in one's PersonalQueue?. 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.
SeparationAndGroupingAreArchaicConcepts
I believe that ManagementOfConcerns? is a more realistic goal because pure separation itself is not practical in many domains. -top
SeparationOfConcerns 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 CrossCuttingConcerns no matter how you try to cut them. SeparationOfConcerns on the smallish scale - i.e. splitting a BigBallOfMud 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 ManagementOfConcerns?. I'd assert that GeneralPurposeProgrammingLanguage's primary task is simplified management of the many CrossCuttingConcerns. -AnonymousDonor
Moved discussion to TableOrientedCodeManagementDiscussion.
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, SolutionSpaces?.
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 UsefulLie. 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 SeparationOfConcerns may violate YagNi.
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 YagNi. 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 StructuredDesign? by Constantine and Yourdon? You do claim to be the Procedural programmer? Have you read any modern book on Refactoring? NickKeighley
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". SoftwareEngineeringIsArtOfCompromise, 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 WetWare 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 PrematureOptimization trumps SeparationOfConcerns. 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:
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 OnceAndOnlyOnce 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. KissPrinciple seems to dictate intermixing validation and formatting. (A DuplicationRefactoringThreshold 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 RealInformation. 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. --JonGrover
That's an interesting notion. Can you provide a simple, concrete illustration that exemplifies the distinction between data and RealInformation? In particular, can you clearly illustrate how data differs from information? There are some relevant -- but unanswered -- questions on the RealInformation page, too.
Typical computing-space concerns include:
SeparationOfConcerns 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:
EditText of this page
(last edited October 29, 2014)
or FindPage with title or text search