Encapsulation - black box?
Day after day, I’m worried about the problem of using someone else’s and my classes and libraries. When after some time you see that your code lacks the ability to redefine the behavior of a class and this interferes, and even worse, when a foreign library does not perform the tasks stated to it, even knowing where to fix and how you are limited by the code that was written in this library without the possibility of overriding. This article structures the encapsulation approach, which will make it possible not to waste time creating bicycles and save the efforts of programmers who use black boxes and create new ones.
Encapsulation is an art, not just a black box. The problem is - code that cannot be fixed, redefined, modified, etc. in the same project where it is used. Everything must be configured, redefined and changed. Universal soldier, who is called in the right situation and he saves the world, not waiting for the birth of a new soldier. And the solution is not to fix the source of libraries, because This is a time consuming process due to the simple lack of source code. It is easy to say these words, but it is more difficult to understand what they mean in programming languages and how to correspond to them.
I want to say that encapsulation problems exist , but they are solved. You can look at the black box as an already finished product that is used to achieve the goal, as well as the material from which the form will be created to achieve the goal. We can give an example of an artist who uses paint for drawing and creates new paints, i.e. configures paints for future use. But if we take instead of paints and give the artist clay, then the desired color of clay will not be obtained by mixing clay (a laborious process). In this case, plasticine is inferior to paints.
Therefore, the use of a black box can be divided into two categories:
In the case of external libraries, “ready-made products” may be justified, but too much of a limitation may lead programmers to the devil's path. The goal of the intermediary, a convenient hidden box, of course, is to help abstract from the intricacies of the implementation, but also to give the opportunity to configure it as much as possible and, accordingly, to expand its use.
')
Principles to consider when creating libraries, black boxes for newly used code:
PS: If the topic is interesting, then I will prepare examples using the principles of OOSILA.
UPDATE: hidden box => black box
Encapsulation is an art, not just a black box. The problem is - code that cannot be fixed, redefined, modified, etc. in the same project where it is used. Everything must be configured, redefined and changed. Universal soldier, who is called in the right situation and he saves the world, not waiting for the birth of a new soldier. And the solution is not to fix the source of libraries, because This is a time consuming process due to the simple lack of source code. It is easy to say these words, but it is more difficult to understand what they mean in programming languages and how to correspond to them.
I want to say that encapsulation problems exist , but they are solved. You can look at the black box as an already finished product that is used to achieve the goal, as well as the material from which the form will be created to achieve the goal. We can give an example of an artist who uses paint for drawing and creates new paints, i.e. configures paints for future use. But if we take instead of paints and give the artist clay, then the desired color of clay will not be obtained by mixing clay (a laborious process). In this case, plasticine is inferior to paints.
Therefore, the use of a black box can be divided into two categories:
- The finished product (relevant for companies that make a profit for the sale and support of the product, MS, Oracle, etc. For this reason, they provide classes that can not be reconfigured)
- Mediator (relevant for OpenSource companies, but paradoxically they forget to give or do not suspect that they do not give the opportunity to configure their classes as much as possible)
In the case of external libraries, “ready-made products” may be justified, but too much of a limitation may lead programmers to the devil's path. The goal of the intermediary, a convenient hidden box, of course, is to help abstract from the intricacies of the implementation, but also to give the opportunity to configure it as much as possible and, accordingly, to expand its use.
')
Principles to consider when creating libraries, black boxes for newly used code:
- Overriden. Make methods with an access operator so that you can override the methods. (at least protected, use very rarely an access level less than protected)
- Overload functions. Diverse signature of the same functions, reduce the number of parameters in methods
- Static is Evil. Static variables, functions evil, which must be replaced with ordinary variables and functions
- Control Instances. Do not create new objects without the ability to override this creation. Do not use the new operator explicitly in code, but use the setters methods for these objects, factories to create objects, or the function to create objects that are overridden
- Last Version is Evil. Do not use the final keyword for functions and classes. Allow override functions and classes
- Atomic. To isolate all logical units into small methods
PS: If the topic is interesting, then I will prepare examples using the principles of OOSILA.
UPDATE: hidden box => black box
Source: https://habr.com/ru/post/136518/
All Articles