Separation of Concerns: a Fundamental Principle
In the last part, the concept of complexity was introduced and explored to some extent. Now the question is how to deal with it. The well-known rule for this is: break it into simpler, smaller elements where each element is simple enough to be comprehended and understood easily. We all have heard this time and time again, and this is in fact the principle on which complexity is solved; this is called analysis and is the essence of problem-solving. But, how actually this is done, is not shown as many times. Anyways, for our purposes – programming and design – there is one principle which will help achieve this and it is called the Separation of Concerns Principle (SoC). When it comes to designing programs, software applications or systems, this is one of the most fundamental principles there so much that most other principles can be derived from it one way or another.
In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections such that each section addresses a separate concern. A concern is a set of information that affects the code of a computer program.
As an example of separation of concerns at work, consider the REST architecture paradigm. Before REST (and web services), traditional old web applications mixed the back-end logic and front-end. For example, a web application would fetch the data from the server, for example a partially processed Java data-structure, and perform the rest of logic at the client and then show it. Each client request was tied to a specific function at the server. Then it was realized that these two aspects are separate and need not, should not, be mixed. The back-end service provides data, and does not know who uses it and how. It could be shown on a web page, a mobile app or read by a query from another application. The client does not know how the data is produced and receives it in a platform-independent format, e.g. in JSON.
https://api.zestard.com/wp-content/uploads/2015/12/What-is-Rest-API-02-1.jpg
Please be cautioned about one thing though, most design principles including SoC were developed or mostly used within the context of object-oriented programming (OOP) which dominated the field of software engineering and design since the 1990s. Hence, their explanations, including the source cited above, mostly refer to object-oriented terms such as information hiding, encapsulation etc. In practice, to many people they have been associated and tied to OOP, so much that not many consider using them outside of this realm. But, in essence they are general and the reader should focus on their general aspect. In fact, SoC for example, is a very general principle that goes not only beyond OOP but even beyond programming, and applicable to many diverse fields, e.g. to situations like division of labour between collaborating teams etc. The objective of this writing is to exactly do this: bring general ideas from the principles out; adapt and apply them to data-processing programming.
Modularity
In any program design, modularity is of crucial importance. Principle of modularity in design is based on SoC.
Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.
So far, all these principles and concepts e.g. complexity, SoC, concerns, modularity etc are kind of abstract to someone not very familiar with them. Things like, what really is a concern, how to identify and separate them, and so on maybe not not clear. But, starting from the next part, principles are put to action by showing how each is applied to concrete programming problems.