Separation of Concerns

Imaginary world

Let's pretend we have an imaginary world where you are given a project with requirements which never change, and you have the opportunity to plan for it. Well then… in that case:

"Separation of Concerns" is common sense.

Example 1: "Separation of Concerns" is natural. The concept is found at work in our bodies. My heart does not need to know what my kidneys are doing in order to work. Sure, if my kidneys fail, that'll cause issues for my body as a whole. But they're 'modular' I could even get a transplant (disclaimer: I'm not a doctor) without my heart noticing (I think).

Example 2: Perhaps I made "Separation of Concerns" sound sophisticated before by relating it to something as incredible as the human body. Let's look at something more simple like a flashlight. Flashlights require some power source. Lets say a battery (AA, AAA, D, etc…). The flashlight has one requirement from a battery: that the battery produces the correct voltage with a certain current. It doesn't need to know how that current is made. Heck, you could power a flashlight from the wall, it wouldn't know the difference.

Lets say for some strange reason you wanted to have the flashlight rely on the power source. In this case, you would have to do something completely out of your way, which is obviously a waste of time, such as creating your own batteries which have a circuit that interacts with a circuit inside of the flashlight. Making it so that if you change the inner-workings of the flashlight, you would have to produce a brand new battery which would be able to work with the updated flashlight. All that complexity of making the battery integrate with the flashlight circuit for… what?

The point of these examples, is that when you have hindsight, it is common sense to isolate things into modules. We see that it happens in nature, it happens without thinking twice about it, these advanced devices called flashlights have been demonstrating "Separation of Concerns" for years before computers. Flashlight manufacturers never felt the need to coin a term after how modular flashlights are.

However, this is all in a perfect world where you are able to plan for things that don't change. The truth of the matter is that unless you are writing something which is 100% clearly defined, your project's requirements are going to change.

The Real World

What happens in the real world is that you start off with a project that has requirements, people work on these requirements, and always the original requirements will change, at least a little. We will start off trying to make a flashlight and realize what we really needed was a strobe light array with five different lights and an entire control cabinet.

Suppose the original designers planned for making a flashlight. They did their obvious "Separation of Concerns". So they made the bulb so that it doesn't depend on anything in the flashlight circuit, then also made it so that the switch can be replaced without changing the flashlight circuit too.

With this pretty flashlight the developers finished, they will slowly come to the realization that they need to support five bulbs instead of one. Of course this change will require a change in the flashlight circuit as well as the bulbs. A developer could take two different routes:

  1. Make small changes to the flashlight circuit code so that it accepts five of our already modular bulbs. (Maybe adding some keyword
  2. Re-write part of the flashlight circuit so that there are sub-circuits which are completely independent ("Separation of Concerns")

This is when "Separation of Concerns" stops being common sense, and begins being an active choice a developer should stop and think about. The earlier someone chooses the second path, the cleaner things will be down the road.