The art of programming under Unix (and not only). Part Four, “The Rule of Separation”

I continue the series of articles devoted to some simple development rules for Unix "according to Eric Raymond ", which, in my deepest conviction, can be extended to any other operating systems. I already talked in the first three parts about the rules of modularity , clarity and  composition . Today, it comes to the fourth rule -

The separation rule: separate the rules from the mechanism, and the interfaces from the engine ( “business logic” ) (Rule of Separation: Separate policy from mechanism; separate interfaces from engines)

Many web programmersthey will probably find the rule rather banal. After all, this principle is fundamental for millions of frameworks and content management systems for sites, and they are the basis for almost any modern web solution . Nevertheless, you increasingly notice that you observe this principle more often only when developing a product from scratch, and then violate it in every way with its support and development. Because "it was urgent." Secondly , in the rest of the software, except for websites , it is remembered less and less. After all, interfaces can be not only web interfaces .

In connection with this topic, we should recall the concept of Model-View-Controller, or abbreviated MVC. It is supposed to separate data (Model), representation (View) and  business logic (Controller). Simply put, all logic, all interfaces and all data must be separated from each other by different components and connected by standard interfaces. This design pattern is implemented for almost all modern programming languages. From the popular “classics” we can recall Apache Struts (JAVA), Symfony ( PHP ), ASP.NET MVC. The use of well-documented, widely used frameworks for this purpose is much more preferable than writing them from scratch yourself, because you don’t have to lay any specifics for the problem to be solved, and most likely it will be nothing more than the invention of a bicycle and time wasting and resources.

A very interesting example of separation of interface and logic is the implementation of chess for Unix, distributed under the GNU license. There is a separate chess engine with a text interface. Inside it, the interface is also separated from the "logic", but - importantly - it was not intentionally "burdened" on purpose. Blackboard with figures are separate applications like XChess, Pychess, Winboard.

A classic example of using this concept is the implementation of the X Window System, a window system that does not have its own graphical environment. The rendering of “windows” and “icons” is done by third-party window managers, who, in turn, are devoid of “mathematics” and do not care about supporting I / O devices .

Part of this principle is the separation of rules from mechanisms. It is about building flexible, customizable data-based logic. Here, unfortunately or fortunately, there is no universal advice on where to draw the line between flexibility and sufficiency. For example, you can rely on different screen resolutions when designing an application for iPhone, and this will definitely help if the question arises of porting to iPad. This will definitely require additional effort and time. Therefore, the product manager or the person replacing him must be involved here, and the programmer's task is to correctly and timely raise these issues in a clear and understandable form.

One of the difficult situations when observing this principle is the use of Javascript together with server logic. When creating systems that actively use AJAX, you need to carefully monitor this at the design stage. A very common mistake is the excessive complexity of site templates with Javascripts , as a result of which they turn into a complex system. Therefore, every time when you plan to actively use Javascript, take a coordinated approach in the development team, as in this case, separate business logic and interfaces.

"  Earlier: composition rule

Continuation: rule of simplicity  "