![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||
|
I think the use of the term "separation of concerns" to define one of the fundamental goal of (almost) all analysis and design paradigms (not just software) is both interesting and appropriate. I like the general nature of the term and suggest that terms like "encapsulation" are specific attributes of a particular approach to "separation of concerns" in the context of a software design methodology.
I do question, however, the implied equivalence of "encapsulation" and "transparency of operation". And, I suggest that the latter requires explanation. Exactly how does "transparency of operation" relate to "separation of concerns"?
Imaginit ( talk) 15:27, 15 April 2010 (UTC)
The last part of this sentence, in the first paragraph of the 'implementation' section: "a design pattern like MVC can separate content from presentation and data-processing (model) from content" seems incomplete. I think the desired meaning is, basically, "MVC can separate content from both presentation and data-processing (ie, model)" but the phrasing is rather obscure, no?
I don't want to comment on the above, but I would like to point out that MVC is an architectural pattern not a design pattern Mastmead ( talk) 16:33, 31 October 2012 (UTC)
The article says that "the term separation of concerns was coined by David Parnas in his paper 'On The Criteria To Be Used in Decomposing Systems into Modules'." However, I could not find the expression in the paper. -- Picuinhas 5 July 2005 18:24 (UTC)
The term "separation of concerns" is used in the 1974 paper from Edsger W. Dijkstra, On the role of scientific thought:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
Eddie Burris
This whole article strikes me as original research. Is there a verifiable source for the content of this article? Dijkstra's use of the term to mean separating concerns like the concern for correctness, the concern for performance, the concern for safety, the concern for concurrency etc. bears little resemblance to the article here. Arbitrary features are not concerns--all relevant concerns affect all features. While one can use abstraction, functional decomposition and information hiding as implementation techniques to separate concerns within a language, considering separate concerns in isolation can use entirely different languages for each concern.
This use of separate languages for separate concerns is, in fact, quite common--even though, not always readily apparent. Thus one might deal with the concern for correctness with a high-level language. One might deal with the concern for performance in other languages comprising make-file syntax, command-line switches and pragmas, while the compiler itself addresses the concern for performance by transforming the original program through a series of other internal languages using symbolic manipulation.
Equating the separation of concerns with abstraction, functional decomposition or information hiding, as this article seems to, strikes me as a very limiting misconception.
Bob Badour 17:46, 25 June 2006 (UTC)
I found the article very informative. Mr. Badour's criticisms seem muddled.
If his complaint is that the information is original research (i.e., not based on peer-reviewed published research), then his numerous references to Mr. Dijkstra's unpublished, non-peer-reviewed, informal e-mails seem only to exacerbate the problem.
If his point is that neither object-orientation nor aspect-orientation have standing as an intellectual discipline, but are merely buzzwords, then perhaps he can back this idiosyncratic assertion with some citations. I find that any review of, e.g., aspect oriented research shows it has separation of concerns as a primary concern, and thus is entirely relevant to a discussion of Separation of Concerns as a topic in the Wikipedia.
-- June 29, 2006
I removed the 'Real Life Examples' Section. It talks about artificial concerns and such like that aren't referenced in the main article and is just plain confusing. I don't know the subject well enough to write a section but I really think a 'Real Life Examples' section could be very handy, if someone can think of a related analogy 212.56.97.238 16:44, 31 January 2007 (UTC)
Whoops. Forgot to login. That was me. NatashaUK 16:45, 31 January 2007 (UTC)
Every time there is a change in human affairs, it usually involves lumping or splitting. I learned this very early in life and saw the concept repeated as programming principles: "coupling and cohesion", "orthogonality", "DRY (don't repeat yourself)", "normalization", "etc.", and now "Separation of Concerns". Is there some fundamental principle that everyone is overlooking? Is SoC orthogonal in a meta-sense?
I removed some text that's a direct copy from another Wiki ( http://www.aosd.net/wiki/index.php?title=Glossary#Separation_of_Concerns). That wiki has CC-licensed text and "users own their edits" too. I was going to email the webmaster asking for permission to use the text, but thought it would be better to find similar language in a book or to paraphrase it. Unfortunately, it's already simple and straightforward and I can't come up with a good way to rephrase it without making it incorrect. I'll check through any books I have referring to SoC, but please help in replacing this text with a verifiable source. Thanks! mordel ( talk) 14:05, 12 February 2008 (UTC)
The title says it all. —Preceding unsigned comment added by 88.77.138.219 ( talk) 00:54, 10 March 2009 (UTC)
No. Decomposing a program or system into modules is a technique concerned with the representation of source on one hand, and deployable parts on the other. That is, it is about packaging, or the syntax (using the term loosely) of how the system is represented. Separation of concerns is about really about the interdependencies that arise within the system from how the features for the system are conceived. That is, it is about formulation, or well-definedness and soundness. Modularization may be motivated by SOC, but it may also be pursued informally and for other reasons. Many of those interested in the subject are informed by mathematics; "consultant" could be a disparaging term in this context. Dijkstra himself seems to have preferred explicit formal reasoning in writing programs, over appeals to intuition. — Preceding unsigned comment added by 75.189.231.100 ( talk) 16:06, 24 December 2011 (UTC)
The beginning of article is confusing. It states, that "(SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible."
This is not true. SoC is a paradigm/methodolgy to break a _problem_ into distinct, funktionally non overlapping features, from where a computer program can be constructed by composition mechansm of the programming language. SoC itself is a programming paradigm and in case of AOP (fex. AspectJ, java AOP extension) a methodolgy.
Paradigm part is (indirectly) stated in Hürsch et al (1995) paper, http://eprints.kfupm.edu.sa/64610/. They also state, that SoC is a driving engineering principle at conceptual level. Dont really knowm if they mean classic engineering or software engineering. Propably the former.
In AOP and AspectJ, this has been established as a methodology.
This should be discussed and rewritten.
K4hv1 ( talk) 11:29, 28 April 2009 (UTC)
I proposed that Core concern and Concern (computer science) be merged into this article, primarily because I didn't understand the context until I read all three articles. If merged, I think it'll provide the reader with context, as opposed to the confused state of the current articles. -- Robin ( talk) 17:51, 25 August 2009 (UTC)
The first sentence of this article should have two things:
MisterSheik ( talk) 23:24, 8 August 2010 (UTC)
The section on partial classes seems an odd thing to include as it is not necessarily a good example of separating concerns, and is often a counterexample (the motivating example might be considered as such). A well designed class is supposed to represent a separated concern; further dividing it into partial classes suggests that there are more classes at play, as per Single responsibility principle. Far from separating concerns, partial classes can mess up the presentation of related concerns.
PietMoor ( talk) 12:22, 17 July 2012 (UTC)
Agreed. The example of using partial classes to cut some features that a client hasn't paid for is ridiculous and completely unrealistic as well. 109.130.29.156 ( talk) 12:47, 17 May 2015 (UTC)
From [Thousandth of an inch], it'd seem that the term also has some usage in mechanics, although i couldn't find a ref thru a quick net-search. It'd be interesting to see wehther Dijkstra actually imported the concet from antoher field to CS. --J Etienne, 17/6/13 — Preceding unsigned comment added by 152.77.24.38 ( talk) 07:31, 17 June 2013 (UTC)
This article states that modularity "is achieved by encapsulating INFORMATION inside a section of code that has a well-defined interface". This is a limited perspective, because a program (and software) is something that EXECUTES; a program IS behavior, and HAS (or operates on) data. There may be modulatory of data, but modularity of a PROGRAM means entails well-interfaced modules of BEHAVIOR. A program is not a collection of "smart data", but consists of a SYSTEM of data/objects and the behaviors of the SYSTEM. Objects may properly contain methods that act on the object as an atomic unit, but it does not make sense to slice up SYSTEM behaviors along DATA boundaries.
There may be concerns of the data, and concerns of the behavior of the system, but the two are not the same, and data is not what a program IS. In fact, data and system behavior are themselves two separate concerns, and SOC thus encourages them to be expressed separately. The DCI paradigm focuses on this ability (see the "Data Context Interaction" wiki page).
The article also defines a concern as "a set of INFORMATION that affects the code". Though not incorrect, this does paint a more data-centric view of software, and thus a more general word may be more appropriate (e.g. aspect, issue, topic). — Preceding unsigned comment added by Shkaboinka ( talk • contribs) 11:28, 14 November 2015 (UTC)
Is SoC really a well known and used acronym? I have never seen this used before 71.127.210.99 ( talk) 02:09, 10 July 2022 (UTC)
Facebook 175.100.14.220 ( talk) 14:43, 31 May 2023 (UTC)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||
|
I think the use of the term "separation of concerns" to define one of the fundamental goal of (almost) all analysis and design paradigms (not just software) is both interesting and appropriate. I like the general nature of the term and suggest that terms like "encapsulation" are specific attributes of a particular approach to "separation of concerns" in the context of a software design methodology.
I do question, however, the implied equivalence of "encapsulation" and "transparency of operation". And, I suggest that the latter requires explanation. Exactly how does "transparency of operation" relate to "separation of concerns"?
Imaginit ( talk) 15:27, 15 April 2010 (UTC)
The last part of this sentence, in the first paragraph of the 'implementation' section: "a design pattern like MVC can separate content from presentation and data-processing (model) from content" seems incomplete. I think the desired meaning is, basically, "MVC can separate content from both presentation and data-processing (ie, model)" but the phrasing is rather obscure, no?
I don't want to comment on the above, but I would like to point out that MVC is an architectural pattern not a design pattern Mastmead ( talk) 16:33, 31 October 2012 (UTC)
The article says that "the term separation of concerns was coined by David Parnas in his paper 'On The Criteria To Be Used in Decomposing Systems into Modules'." However, I could not find the expression in the paper. -- Picuinhas 5 July 2005 18:24 (UTC)
The term "separation of concerns" is used in the 1974 paper from Edsger W. Dijkstra, On the role of scientific thought:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
Eddie Burris
This whole article strikes me as original research. Is there a verifiable source for the content of this article? Dijkstra's use of the term to mean separating concerns like the concern for correctness, the concern for performance, the concern for safety, the concern for concurrency etc. bears little resemblance to the article here. Arbitrary features are not concerns--all relevant concerns affect all features. While one can use abstraction, functional decomposition and information hiding as implementation techniques to separate concerns within a language, considering separate concerns in isolation can use entirely different languages for each concern.
This use of separate languages for separate concerns is, in fact, quite common--even though, not always readily apparent. Thus one might deal with the concern for correctness with a high-level language. One might deal with the concern for performance in other languages comprising make-file syntax, command-line switches and pragmas, while the compiler itself addresses the concern for performance by transforming the original program through a series of other internal languages using symbolic manipulation.
Equating the separation of concerns with abstraction, functional decomposition or information hiding, as this article seems to, strikes me as a very limiting misconception.
Bob Badour 17:46, 25 June 2006 (UTC)
I found the article very informative. Mr. Badour's criticisms seem muddled.
If his complaint is that the information is original research (i.e., not based on peer-reviewed published research), then his numerous references to Mr. Dijkstra's unpublished, non-peer-reviewed, informal e-mails seem only to exacerbate the problem.
If his point is that neither object-orientation nor aspect-orientation have standing as an intellectual discipline, but are merely buzzwords, then perhaps he can back this idiosyncratic assertion with some citations. I find that any review of, e.g., aspect oriented research shows it has separation of concerns as a primary concern, and thus is entirely relevant to a discussion of Separation of Concerns as a topic in the Wikipedia.
-- June 29, 2006
I removed the 'Real Life Examples' Section. It talks about artificial concerns and such like that aren't referenced in the main article and is just plain confusing. I don't know the subject well enough to write a section but I really think a 'Real Life Examples' section could be very handy, if someone can think of a related analogy 212.56.97.238 16:44, 31 January 2007 (UTC)
Whoops. Forgot to login. That was me. NatashaUK 16:45, 31 January 2007 (UTC)
Every time there is a change in human affairs, it usually involves lumping or splitting. I learned this very early in life and saw the concept repeated as programming principles: "coupling and cohesion", "orthogonality", "DRY (don't repeat yourself)", "normalization", "etc.", and now "Separation of Concerns". Is there some fundamental principle that everyone is overlooking? Is SoC orthogonal in a meta-sense?
I removed some text that's a direct copy from another Wiki ( http://www.aosd.net/wiki/index.php?title=Glossary#Separation_of_Concerns). That wiki has CC-licensed text and "users own their edits" too. I was going to email the webmaster asking for permission to use the text, but thought it would be better to find similar language in a book or to paraphrase it. Unfortunately, it's already simple and straightforward and I can't come up with a good way to rephrase it without making it incorrect. I'll check through any books I have referring to SoC, but please help in replacing this text with a verifiable source. Thanks! mordel ( talk) 14:05, 12 February 2008 (UTC)
The title says it all. —Preceding unsigned comment added by 88.77.138.219 ( talk) 00:54, 10 March 2009 (UTC)
No. Decomposing a program or system into modules is a technique concerned with the representation of source on one hand, and deployable parts on the other. That is, it is about packaging, or the syntax (using the term loosely) of how the system is represented. Separation of concerns is about really about the interdependencies that arise within the system from how the features for the system are conceived. That is, it is about formulation, or well-definedness and soundness. Modularization may be motivated by SOC, but it may also be pursued informally and for other reasons. Many of those interested in the subject are informed by mathematics; "consultant" could be a disparaging term in this context. Dijkstra himself seems to have preferred explicit formal reasoning in writing programs, over appeals to intuition. — Preceding unsigned comment added by 75.189.231.100 ( talk) 16:06, 24 December 2011 (UTC)
The beginning of article is confusing. It states, that "(SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible."
This is not true. SoC is a paradigm/methodolgy to break a _problem_ into distinct, funktionally non overlapping features, from where a computer program can be constructed by composition mechansm of the programming language. SoC itself is a programming paradigm and in case of AOP (fex. AspectJ, java AOP extension) a methodolgy.
Paradigm part is (indirectly) stated in Hürsch et al (1995) paper, http://eprints.kfupm.edu.sa/64610/. They also state, that SoC is a driving engineering principle at conceptual level. Dont really knowm if they mean classic engineering or software engineering. Propably the former.
In AOP and AspectJ, this has been established as a methodology.
This should be discussed and rewritten.
K4hv1 ( talk) 11:29, 28 April 2009 (UTC)
I proposed that Core concern and Concern (computer science) be merged into this article, primarily because I didn't understand the context until I read all three articles. If merged, I think it'll provide the reader with context, as opposed to the confused state of the current articles. -- Robin ( talk) 17:51, 25 August 2009 (UTC)
The first sentence of this article should have two things:
MisterSheik ( talk) 23:24, 8 August 2010 (UTC)
The section on partial classes seems an odd thing to include as it is not necessarily a good example of separating concerns, and is often a counterexample (the motivating example might be considered as such). A well designed class is supposed to represent a separated concern; further dividing it into partial classes suggests that there are more classes at play, as per Single responsibility principle. Far from separating concerns, partial classes can mess up the presentation of related concerns.
PietMoor ( talk) 12:22, 17 July 2012 (UTC)
Agreed. The example of using partial classes to cut some features that a client hasn't paid for is ridiculous and completely unrealistic as well. 109.130.29.156 ( talk) 12:47, 17 May 2015 (UTC)
From [Thousandth of an inch], it'd seem that the term also has some usage in mechanics, although i couldn't find a ref thru a quick net-search. It'd be interesting to see wehther Dijkstra actually imported the concet from antoher field to CS. --J Etienne, 17/6/13 — Preceding unsigned comment added by 152.77.24.38 ( talk) 07:31, 17 June 2013 (UTC)
This article states that modularity "is achieved by encapsulating INFORMATION inside a section of code that has a well-defined interface". This is a limited perspective, because a program (and software) is something that EXECUTES; a program IS behavior, and HAS (or operates on) data. There may be modulatory of data, but modularity of a PROGRAM means entails well-interfaced modules of BEHAVIOR. A program is not a collection of "smart data", but consists of a SYSTEM of data/objects and the behaviors of the SYSTEM. Objects may properly contain methods that act on the object as an atomic unit, but it does not make sense to slice up SYSTEM behaviors along DATA boundaries.
There may be concerns of the data, and concerns of the behavior of the system, but the two are not the same, and data is not what a program IS. In fact, data and system behavior are themselves two separate concerns, and SOC thus encourages them to be expressed separately. The DCI paradigm focuses on this ability (see the "Data Context Interaction" wiki page).
The article also defines a concern as "a set of INFORMATION that affects the code". Though not incorrect, this does paint a more data-centric view of software, and thus a more general word may be more appropriate (e.g. aspect, issue, topic). — Preceding unsigned comment added by Shkaboinka ( talk • contribs) 11:28, 14 November 2015 (UTC)
Is SoC really a well known and used acronym? I have never seen this used before 71.127.210.99 ( talk) 02:09, 10 July 2022 (UTC)
Facebook 175.100.14.220 ( talk) 14:43, 31 May 2023 (UTC)