Talk:Separation of concerns

message: 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)
thread_title:  encapsulation 

message: 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)
thread_title:  sentence quibble? 

message: 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)
thread_title:  Removal 

message: 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? 
:--jwalling 01:56, 5 February 2007 (UTC)
thread_title:  Lumping or Splitting 

message: 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)
thread_title:  Copyright violation 

message: The title says it all.  —Preceding unsigned comment added by 88.77.138.219 (talk) 00:54, 10 March 2009 (UTC)
thread_title:  Isn't this just a fancy “consultant” name for “modularization” 

message: 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)
thread_title:  The beginning of article 

message: 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)
replies: text: Core concern should definitely be merged with Concern (computer science). It's too short and gives no useful information beyond saying that a core concern is an important one. I've got to look over the IBM stuff linked at Concern (computer science) to see if it has some merit on its own beyond being a WP:DICTDEF needed to understand this article. Pcap ping 19:59, 25 August 2009 (UTC)

text: By the way, core concern is linked from Cross-cutting concern, where it's needed to explain the notion. It it's merged only with Concern (computer science), there's no biggie. If its merged here, it's more troublesome, as it's not needed here, so it there's not much reason to define it in the lead... Pcap ping 20:06, 25 August 2009 (UTC)

text: Oppose : Topics are worth of their own article. They can be referenced. --Camilo Sanchez (talk) 19:24, 18 November 2010 (UTC)

text: Support. Concern (computer science) contains a one-paragraph definition followed by an explanation of separation of concerns. It seems that separation of concerns is the context in which concern is notable. --Pnm (talk) 00:16, 5 December 2010 (UTC)

text: Oppose... Yeah, a bit terse in one case, but otherwise Okay. DOING THE WORK, then redirection of the short page OK by me. // FrankB 23:25, 15 May 2011 (UTC)

text: * Posted this comment today, closing discussion:<br
/>By Fabartus, 15 May 2011: Merge proposal failed of interest, vote count in reasonable amount of time; today documented the tagging event discussion, history by commenting out. // FrankB 23:25, 15 May 2011 (UTC)
thread_title:  Merger proposal 

message: The first sentence of this article should have two things: 
* Description: A brief description of what separation of concerns is
* Motivation: A brief description of why it is important.
MisterSheik (talk) 23:24, 8 August 2010 (UTC)
thread_title:  Motivation 

message: 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)
thread_title:  Partial Classes as Counterexample? 

message: 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)
thread_title:  Origin 

message: 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)
thread_title:  Behavioral concerns 

message: 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)
thread_title:  SoC