title	tags	created	published
Separation of Concerns	article software	2018-06-25T00:16:40Z	true

Do one thing and do it well.

Separation of concerns is a concept that can be described as the art of only doing what the tool should be concerned with, never more than needs to be done. You don't expect a knife to function as a lighter. A knife only needs to cut and it does that one thing very well.

How does this apply to software?

Any type of modern software architecture allows us to structure our code into modules, packages, files, libraries, engines and other types of abstractions that let us reuse existing functionality.

Whenever you write a new module, ask yourself this: Does this module really need to contain all the code it has inside it? Is every part of this module really dealing with the same problem, the same concern?

Chances are high that you have written a module in the past that does much more than it needs to do. The module is doing things that it should not be concerned with. These different concerns should be separated into different modules, each dealing only with the bare minimum they need to deal with.

What's the benefit?

By doing so, you will notice that your code gains a higher chance of being reused in a different project. Modules can be tested much easier because the amount of possible states you need to reason about becomes much smaller, therefore contributing to overall better software quality.

What about frameworks?

This is actually one of the main reasons I don't like monolithic frameworks. You import one package (the framework) and it concerns itself with a multitude of problems. It becomes hard to test and reason about this software. Understanding and fixing bugs becomes difficult because it deals with so many things, the faulty state could have been caused by any part of the system.

Instead, what software developers should strive for, is to make small and independent packages that deal with a single problem only. Do not offer a single package that deals with all of the world's problems, offer a set of modules that developers can choose from. By doing so, a framework becomes a specification of modules, a concept, rather than an actual package with thousand dependencies.

Conclusion

• Separate concerns.
• Do one thing and do it well.
• Avoid centralism, prefer composition.