About abstraction, loosely coupled architecture and design in general
To good posts "Code in the style of" dump of the stream of consciousness " " and "Micro-refactoring, which we so often forget . "
Of course, many of you will find that the answers given below to these questions are quite familiar, but take this article to note, since it is often much more comfortable to throw a link than to grovel in explanations and evidence of the obvious.
')
A very frequent case is that when we are at the entrance we have an excellent program that is written in one breath, and is good at the fact that it works and does what is necessary.
It would seem that you can rejoice, but there are some circumstances from the harsh real life, not noticeable behind the pink glasses.
1. Any program has bugs. Therefore, it must be accompanied.
2. In any program, sooner or later you need to make changes. Therefore, it must be accompanied.
3. Any program or parts of it may become components of another program. And the original decisions will have to accompany.
It makes sense to write each program taking into account that someone will accompany it. Your code will be read by other programmers, and only according to your code will they draw conclusions about your moral character. And very often you yourself will be this “other programmer”. Axiom, is not it, right?
Did everyone have to go back to analyzing their own code?
Consider a typical example - a cool program, where all the code is lumped together.
This is what happens when in the same component there are:
- final output and data acquisition;
- data processing of obviously different nature;
- deployed algorithms in the bodies of nested conditions.
In fact, it would seem, why carry a couple of lines of code into a separate method (function)? For some, it will be amazing, but it makes sense.
The strongest method of programming is abstraction - the division of the program and all its components into parts.
Loosely-connected architecture is a bear power in programming. It was thanks to her that such good things as CodeIgniter, YII, jQuery, Chomium, Half Life, Counter Strike came to light, for example - the list is huge.
The idea of ​​a weakly connected architecture is that the components of the program at various levels have little or no dependence on each other.
For example, in a class, one or several, obviously small number of “dispatching” functions are allocated, which are called by other methods to perform tasks, including private class methods.
High-level examples are known to all users of frameworks - there are sets of components that can be used or not used, depending on actual needs.
The key element of the weakly connected architecture is the selection of a central component. Even formalized API can act as such solution. Naturally, when developing a new product, the API can and will develop along with the development, and be revised several times.
There is one more strength - it makes sense to devote a large amount of attention to the central component, and thus the time for documenting and commenting on the rest is probably saved. By itself, being able to prioritize saves time.
A good solution is to use a loosely coupled architecture at various levels of the application. Then even the most complex Data Flow scheme will be easy to read.
There is always the temptation to sit down and write a solution in one fell swoop, from the head. This I myself often sin.
At the stage of writing code, in most cases there are no problems. Problems appear later, which is highlighted at the beginning of the article.
The main unpleasant consequence of all the problems is the loss of time. Often these time losses are huge and fatal in their consequences. And to prevent and minimize them is not so difficult.
It makes sense to pause here and type the phrase “program design” in Google. All the methods found will be graphical, simple and accessible to understand and use.
The meaning is simple:
- paying more attention to the analysis of the task,
- separating the methods of analysis (including programming, frameworks, algorithms) from the objectives,
- not giving too much priority to one of the elements on the diagram above (“everything is important to us”),
... we save a huge amount of time, money, effort, and also pump our own reputation in the eyes of colleagues.
Designing programs is no less important and useful step than mastering PL, acquaintance with libraries, frameworks and technologies. You can go very far forward, and effectively solve the problems outlined above, paying enough attention to this beautiful aspect of programming.
- Why most programmers do not like to read someone else's code?
- Why does refactoring and making changes become a serious problem?
- Why does it happen so often that it is easier to rewrite from scratch?
- Why do some programmers call others good or bad words?
Of course, many of you will find that the answers given below to these questions are quite familiar, but take this article to note, since it is often much more comfortable to throw a link than to grovel in explanations and evidence of the obvious.
')
- Noodles
- Abstraction
- Loosely coupled architecture
- Code from the head?
Noodles
A very frequent case is that when we are at the entrance we have an excellent program that is written in one breath, and is good at the fact that it works and does what is necessary.
It would seem that you can rejoice, but there are some circumstances from the harsh real life, not noticeable behind the pink glasses.
1. Any program has bugs. Therefore, it must be accompanied.
2. In any program, sooner or later you need to make changes. Therefore, it must be accompanied.
3. Any program or parts of it may become components of another program. And the original decisions will have to accompany.
It makes sense to write each program taking into account that someone will accompany it. Your code will be read by other programmers, and only according to your code will they draw conclusions about your moral character. And very often you yourself will be this “other programmer”. Axiom, is not it, right?
Did everyone have to go back to analyzing their own code?
Consider a typical example - a cool program, where all the code is lumped together.
This is what happens when in the same component there are:
- final output and data acquisition;
- data processing of obviously different nature;
- deployed algorithms in the bodies of nested conditions.
In fact, it would seem, why carry a couple of lines of code into a separate method (function)? For some, it will be amazing, but it makes sense.
Abstraction
The strongest method of programming is abstraction - the division of the program and all its components into parts.
- The business logic of the application is distributed across the class system, based on the subject entities, functionality, stages and types of processed-transmitted information (MVC)
- The application consists of several virtually unrelated components. Often they are even written in different PL, and interact through the API. For example, for a thick toy - layer BL, physics, sound, rasterizer. Physics and graphics - Ogre in C ++, business logic, GUI and sound - Lua or Python. For a website, there are separate components of a web server, an interpreter, CMS in an interpreted language, separate programs for image and video processing, a driver and a database engine.
- Within the same class, the division of actions into different methods (functions) according to a functional feature. Private methods are separated, at least in order to designate data processing that is relevant only for the internal purposes of the class, and information that is of value and value to the user of the class.
Loosely coupled architecture
Loosely-connected architecture is a bear power in programming. It was thanks to her that such good things as CodeIgniter, YII, jQuery, Chomium, Half Life, Counter Strike came to light, for example - the list is huge.
The idea of ​​a weakly connected architecture is that the components of the program at various levels have little or no dependence on each other.
For example, in a class, one or several, obviously small number of “dispatching” functions are allocated, which are called by other methods to perform tasks, including private class methods.
High-level examples are known to all users of frameworks - there are sets of components that can be used or not used, depending on actual needs.
The key element of the weakly connected architecture is the selection of a central component. Even formalized API can act as such solution. Naturally, when developing a new product, the API can and will develop along with the development, and be revised several times.
There is one more strength - it makes sense to devote a large amount of attention to the central component, and thus the time for documenting and commenting on the rest is probably saved. By itself, being able to prioritize saves time.
A good solution is to use a loosely coupled architecture at various levels of the application. Then even the most complex Data Flow scheme will be easy to read.
Code from the head?
There is always the temptation to sit down and write a solution in one fell swoop, from the head. This I myself often sin.
At the stage of writing code, in most cases there are no problems. Problems appear later, which is highlighted at the beginning of the article.
The main unpleasant consequence of all the problems is the loss of time. Often these time losses are huge and fatal in their consequences. And to prevent and minimize them is not so difficult.
It makes sense to pause here and type the phrase “program design” in Google. All the methods found will be graphical, simple and accessible to understand and use.
The meaning is simple:
- paying more attention to the analysis of the task,
- separating the methods of analysis (including programming, frameworks, algorithms) from the objectives,
- not giving too much priority to one of the elements on the diagram above (“everything is important to us”),
... we save a huge amount of time, money, effort, and also pump our own reputation in the eyes of colleagues.
Designing programs is no less important and useful step than mastering PL, acquaintance with libraries, frameworks and technologies. You can go very far forward, and effectively solve the problems outlined above, paying enough attention to this beautiful aspect of programming.
Source: https://habr.com/ru/post/171331/
All Articles