Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If you had a colleague who didn't understand the benefits of Separation of Concerns, or didn't understand it quite enough to apply consistently in their daily work, how would you explain it to them?

share|improve this question
up vote 20 down vote accepted

Imagine you have a program which has been released. A customer comes along and offers to pay you for a enhancement to one of its features. In order to get the money, you will need to change your program to add the new feature. Some of the things that will influence what your profit margin is are:

  1. how much code you have to change
  2. how easy it is to make the changes
  3. how likely you are to break existing features that are being used by other customers
  4. how much you can reuse you existing model/architecture

Separation of concerns helps you to get more positive answers to these questions.

  1. if all of the code for a particular behaviour of the application is separated out, then you will only have to change code directly associated with your new feature. Which should be less code to change.
  2. if the behaviours you are interested in are neatly separated from the rest of the application it is more likely you will be able to swap in a new implementation without having to fully understand or manipulate the rest of the program. It should also be easier to find out which code you need to change.
  3. Code that you do not have to change is less likely to break than code that you do change. So splitting up the concerns helps you to avoid breakage in unrelated features by preventing you from having to change code that they could call. If your features are mixed up together you might change the behavior of one by accident while trying to change another one.
  4. If your architecture is agnostic to technical or business logic detail then changes to implementation are less likely to require new architectural features. For example, if your main domain logic is database agnostic then supporting a new database should be as easy as swapping in a new implementation of the persistence layer.
share|improve this answer

If he/she works in an office, take it as an example, explain the role of each staffs in that office, and ask him, what would happen, if those staffs aren't divided according to their jobs?

share|improve this answer

Look at a hospital, and think about all of the different roles that are involved in providing care to a patient: triage nurses, doctors, medical assistants, techs, clerical staff, cafeteria, etc.

Is there any one person that knows how all of those people get their jobs done? No, because it would be overwhelming. They have to separate out the different responsibilities into distinct roles and the touchpoints between those roles are very specific.

share|improve this answer

I would look at how he failed to apply SoC in his code/design and turn that into a real-world example that he can relate with and that is obviously undesired.

For example, if he has a class where the client needs to supply several pieces of information that are not relevant for those clients, then I would use the analogy of a bakery where you have to bring your own grains and yeast if you want to buy a bread.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.