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 rules for developing under Unix “according to Eric Raymond ”, which, in my deepest conviction, can be extended to any other operating system. I have already told in the first three parts about the rules of modularity , clarity and composition . Today it came 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)
Manyweb programmers will probably find the rule quite banal. After all, this principle is fundamental for millions of frameworks and content management systems of sites, and they are the basis for almost any modern web solution . Nevertheless, more and more you notice that they observe this principle more often only when developing a product from scratch, and then in every possible way violate it with its support and development. Because "it was necessary urgently." Secondly , in part of 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 ofModel-View-Controller , or MVC for short. It is supposed to separate data (Model), view (View) and business logic (Controller). Simply put, all logic, all interfaces, and all data must be separated from each other along different components and connected by standard interfaces. This design pattern is implemented for almost all modern programming languages. From the popular "classics" you can remember Apache Struts (JAVA), Symfony ( PHP ), ASP.NET MVC. Using well-documented, widely used frameworks for this purpose is much more preferable than writing them from scratch to yourself, because there is no need to lay down any specifics for the problem to be solved, and, most likely, this will be nothing more than the invention of a bicycle and time consuming and resources.
A very interesting example of the 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 divided from “logic”, but - importantly - it was not intentionally “weighed down”. The board with figures is separate applications like XChess, Pychess, Winboard.
A classic example of 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 handled by third-party window managers, who, in turn, are deprived of “mathematics” and do not care about the support ofinput-output devices .
Part of this principle is the separation of rules from mechanisms. He - about building flexible, customizable logic based on data. Here, unfortunately or fortunately, there is no universal advice on where to draw the line between flexibility and sufficiency. For example, you can build on a different screen resolution when designing an application for the iPhone and this will definitely help if the issue of porting to the iPad arises. This will definitely require additional efforts and time. Therefore, a product manager or a person who replaces it must necessarily participate here, and the programmer’s task is to correctly and promptly raise these questions in a clear and understandable form.
One of the difficult situations in compliance with this principle is the use of Javascript along 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 complication ofJavascript-s website templates, as a result of which they turn into a complex supported system. Therefore, each time you plan to actively use Javascript, take a coherent approach in the development team, as in this case separate business logic and interfaces.
The separation rule: separate the rules from the mechanism, and the interfaces from the engine (
Many
')
In connection with this topic, we should recall the concept of
A very interesting example of the 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 divided from “logic”, but - importantly - it was not intentionally “weighed down”. The board with figures is separate applications like XChess, Pychess, Winboard.
A classic example of 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 handled by third-party window managers, who, in turn, are deprived of “mathematics” and do not care about the support of
Part of this principle is the separation of rules from mechanisms. He - about building flexible, customizable logic based on data. Here, unfortunately or fortunately, there is no universal advice on where to draw the line between flexibility and sufficiency. For example, you can build on a different screen resolution when designing an application for the iPhone and this will definitely help if the issue of porting to the iPad arises. This will definitely require additional efforts and time. Therefore, a product manager or a person who replaces it must necessarily participate here, and the programmer’s task is to correctly and promptly raise these questions in a clear and understandable form.
One of the difficult situations in compliance with this principle is the use of Javascript along 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 complication of
| " Previously: the rule of composition | Continued: the rule of simplicity " |
Source: https://habr.com/ru/post/103207/
All Articles