Skip to main content

Better Software Design: Separation of Concerns

When I first learned computer programming, I thought I was a fine computer programmer. I produced much code that kind of worked; but looking back on it now I realize that the quality could have been much better. One of the important ideas I have learned since then is separation of concerns.
"We can solve any problem by introducing an extra level of indirection...except for the problem of too many levels of indirection." -Wheeler, et al.
Separation of concerns is the idea that any program that is even a little bit complicated has more than one concern, and that code for each of those concerns should be kept separate in the program. For example, we might write a program that asks a person's name, remembers it, and greets the user back by name. The naive way I would have written this when I started out might have been:
  1. Create a variable to store a person's name
  2. Display a message requesting the person's name
  3. Wait until the user has finished entering input
  4. Move data from user input into the prepared variable
  5. Put together a message greeting the user, getting the name out of the variable
  6. Display the prepared message
That basic sequence might be called business logic. The problem is that real programs are a little more complicated than that basic sequence of business logic. Let's say the first version used an old fashioned text only UI (user interface). The complete program might look like this: (notice the additions in bold)
  1. Create a variable to store a person's name
  2. Use the text only UI to display a message requesting the person's name
  3. Use the text only UI to wait until the user has finished entering input
  4. Use the text only UI to move data from user input into the prepared variable
  5. Put together a message greeting the user, getting the name out of the variable
  6. Use the text only UI to display the prepared message
This starts to be repetitive, but it might still make some sense...until we need to upgrade it. Let's say we discovered that we can use a new graphical UI to display messages and receive input. Using the graphical UI would require different code from the text only UI. Now the new version of the program would need to be:
  1. Create a variable to store a person's name
  2. Use the graphical UI to display a message requesting the person's name
  3. Use the graphical UI to wait until the user has finished entering input
  4. Use the graphical UI to move data from user input into the prepared variable
  5. Put together a message greeting the user, getting the name out of the variable
  6. Use the graphical UI to display the prepared message
Now we have a problem. And, the bigger the program becomes, the bigger problem becomes. Every time we need to use a feature like the UI we need to repeat or copy and paste duplicate code to every area of the program we need to do the same thing. If we want to change the way we use that feature, we must make the same kind of change repeatedly in many different places. As I soon found out as a beginning programmer, that makes it easy to have all kinds of bugs. That is why we need separation of concerns.

In a program, a common reusable feature like the UI is a concern. Each area of code in the program should only have one concern; and each concern should only be dealt with in one area of the program. A program with proper separation of concerns might look more like this:

With Separation of Concerns:
  1. When using the UI
    1. Version 1: use the text only UI
    2. Version 2: use the graphical UI
  2. Use this business logic:
    1. Create a variable to store a person's name
    2. Use the UI to display a message requesting the person's name
    3. Use the UI to wait until the user has finished entering input
    4. Use the UI to move data from user input into the prepared variable
    5. Put together a message greeting the user, getting the name out of the variable
    6. Use the UI to display the prepared message
As you can see, this code is more orderly compact, so if the actual code were very complicated, this arrangement might be easier to understand at a glance. Much smaller changes are required to upgrade from Version 1 to Version 2. This also makes the code much less likely to have bugs. User interfaces and business logic are only a few examples of many possible concerns that can benefit from separation.

However, separating software in this way is not always a good idea: if some code is already very simple and not likely to change, it might actually make it more complicated and therefore worse, to try to separate it into concerns. A good rule of thumb might be:
If you find yourself copying and pasting code, think twice and ask yourself whether this might be a good opportunity to improve the code by implementing separation of concerns.
It made me a much better programmer when I learned to understand these ideas and use them in programming.

Popular posts from this blog

What We're About

About UsMission Statement: We provide a product to make high performing software developers happy by giving them a chance to work in a more self-directed way on software that is more meaningful to them. Core Values (in priority order):Integrity: Honesty, trustworthiness, and faithfulnessPreparation: Research, planning, and goalsReputation: Branding, naming, presence, and networkingProfitability: Product salesProduction: Product development, ideas, online contentImprovement: Research and trainingSupport: Minimal overhead Who We Are
Isaac Serafino is a Software Architect in Omaha, Nebraska. He has a strong experience developing technology solutions. He has long had the dream to lead his own startup business.
Our ProductsSnap Screen™
More efficiently provide a safe environment for using electronic devices. Sends pictures of what is on the display at somewhat random times so user knows they could be observed at any time, but the supervisor does not need to be their watching over their sho…

The Invasion of the Developer Commandos™

I. Why Deploy Commandos? It's hard to find the best people to solve difficult problems. By deploying Developer Commandos™, you can get great software developed without needing to figure out how to find the software developers. II. What are Developer Commandos? Unlike an old fashioned developer, a commando works independently. They manage themselves so you won't need to. III. How Can You Deploy Commandos? A. Create a Project Use a project host like GitHub to create a shared workspace online. Commandos will be able to contribute to your software project through this workspace. B. Obtain Incentives Use a cryptocurrency exchange like Coinbase to purchase an amount of a cryptocurrency such as Ether. You will be able to use this cryptocurrency to provide an incentive for commandos. C. Post Opportunities Use a bounty network such as Gitcoin to post bounties. A bounty describes the software problem you need resolved, and allows you to attach a cryptocurrency incentive for resolving i…