Separation of Concerns

We explored defensive programming in Python and some related topics regarding exception handling in the last lesson. Now let's move on to the next big topic: the separation of concerns.

Separating concerns

This is a design principle that is applied at multiple levels. It is not just about the low-level design (code); it is also relevant at a higher level of abstraction, so it will come up later when we talk about architecture.

Different responsibilities should go into different components, layers, or modules of the application. Each part of the program should only be responsible for a part of the functionality (what we call its concerns) and should know nothing about the rest.

The goal of separating concerns in software is to enhance maintainability by minimizing ripple effects. A ripple effect means the propagation of a change in the software from a starting point. This could be an error or exception triggering a chain of other exceptions, causing failures that will result in a defect on a remote part of the application. It could also be that we have to change a lot of code scattered through multiple parts of the code base, as a result of a simple change in a function definition.