What is separation of concerns? What's a concern?
How might one partition an app into these "different concerns"?
What is separation of concerns? What's a concern?
How might one partition an app into these "different concerns"?
Wikipedia:
In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity and encapsulation, with the help of information hiding.
I post this not to gain rep, but to wonder why you would ask a question that can so easily be answered.
http://en.wikipedia.org/wiki/Separation_of_concerns
In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity and encapsulation, with the help of information hiding.
This principle states that a given problem involves different kinds of concerns, which should be identified and separated to cope with complexity, and to achieve the required engineering quality factors such as robustness, adaptability, maintainability, and reusability. Link
Generally speaking, it means that you segregate your software into distinct areas whose functionality does not overlap.
Wikipedia has a good explanation:
Concerns are the different aspects of software functionality. For instance, the "business logic" of software is a concern, and the interface through which a person uses this logic is another.
The separation of concerns is keeping the code for each of these concerns separate. Changing the interface should not require changing the business logic code, and vice versa.
Model-View-Controller (MVC) design pattern is an excellent example of separating these concerns for better software maintainability.
For more information:
Not really an answer to your question, but if you're interested in this, there's a related design pattern called Dependency Inversion.
Let's say you have a class with a method that needs to be influenced from outside the class, or you need multiple implementations of it, or the fact that it's a method of that class makes unit testing difficult. You can put that method in a completely separate class, and pass the instance of the first class in as a parameter.
This is especially useful when using mock interfaces. You can test the method by passing in mocks for the other class with hard-coded values and expected results.
You know about HTML and CSS? That's separation of concerns right there.
The HTML file (possibly XML) defines the document structure. The CSS file defines how the document is presented on your screen.
It is described at the wikipedia: http://en.wikipedia.org/wiki/Separation_of_concerns
It is the value stated in the Single Responsibility Principle, that a function/class/method should do only one thing. That it should do it all, do it well, and do it only. You can read about it at: http://www.objectmentor.com/resources/articles/srp.pdf
Basically, it means you shouldn't munge your ideas together into a lumpy paste, but you should separate your ideas cleanly in code. If you don't, it is hard to change, test, or debug the code. If you do separate them, then you have some freedom to change. For instance, if you munge your html generator with your query, you will find it hard to change the formatting, and you will find it hard to switch to a different query. If you separate them, then both of those things become easy. Or easier, at least.