Separation of Concerns in Software Design | Alexey Naumov
It is so crucial that 2 out of 5 SOLID principles (Single Responsibility and Interface Segregation) are direct derivations from this concept.
The principle is simple: don’t write your program as one solid block, instead, break up the code into chunks that are finalized tiny pieces of the system each able to complete a simple distinct job.
If we take the lowest level (the actual programming code), SoC instructs us to avoid writing long complex functions. When the function starts to bloat up in size, this is the red flag that the method is possibly taking care of too many things at once.
“Code That Fits in Your Head” mentions the similar thing. Basically, the blog suggests that the number of things going on in one function should be less than or equals to 7.
The application of the Separation of Concerns involve two processes: reduction of coupling and increasing cohesion.
Cohesion is the measure of similarity by the set of duties, level of details, and locality. For example, functions
drawCircleanddrawTriangleare cohesive enough to belong to the same module responsible for drawing, and it feels natural to put these two functions close to each other in the code (high similarity ~ high cohesion).
If we need to jump around between the functions or modules as we're following the logic of the algorithm, this means the code has low cohesion, which is often referred to as a Spaghetti code.
Loose Coupling and High Cohesion -> I should remember this
The primary goal of the system's design is to outline the boundaries for the module's awareness of each other.
The example makes sense. Letting business logic directly access its database even though there is a database gateway will result in production issues.
There are soem concepts I don't know now. I'll come back after doing some research.
Separation of concerns - Wikipedia
In computer science, separation of concerns (sometimes abbreviated as SoC) is a design principle for separating a computer program into distinct sections. Each section addresses a separate concern, a set of information that affects the code of a computer program.
Separation of concerns results in more degrees of freedom for some aspect of the program's design, deployment, or usage. Common among these is increased freedom for simplification and maintenance of code. When concerns are well-separated, there are more opportunities for module upgrade, reuse, and independent development. Hiding the implementation details of modules behind an interface enables improving or modifying a single concern's section of code without having to know the details of other sections and without having to make corresponding changes to those other sections. Modules can also expose different versions of an interface, which increases the freedom to upgrade a complex system in piecemeal fashion without interim loss of functionality.
I had a mob programming session yesterday and guided on how separate applications in Django projects offers advantages, such as better reusability, portability, or maintainability.
In hindsight, the design to have multiple Django applications in one project is related to SoC.
Chicken wings 1200 Yogurt 300 Nori 100 Avocado 200 Protein shake 200
Total 2000 kcal
MUST:
TODO: