Encapsulation is a black box?
Day after day I am worried about the problem of using strangers and my classes and libraries. When after a while you see that in your code there is not enough opportunity to redefine the class’s behavior and this interferes, and even worse, when a foreign library does not fulfill its stated tasks, even knowing where to correct and how the code that was written in this library limits you without the possibility of redefinition. This article structures the encapsulation approach, which will make it possible not to spend too much time creating bicycles and save those efforts of programmers that black boxes use and create new ones.
Encapsulation is an art, not just a black box. There is a problem - a code that cannot be fixed, redefined, changed, etc. in the same project where it is used. Everything must be configured, redefined, and modified. A universal soldier who is called in the right situation and he saves the world, and not the expectation of the birth of a new soldier. And the solution is not to fix the source code of the libraries, because This is a time-consuming process due to the simple lack of source. 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 there are encapsulation problemsbut they are solved. You can look at the black box as a finished product that is used to achieve the goal, and the material from which the form will be created to achieve the goal. You can give an example with an artist who uses paints for drawing and creates new paints, i.e. configures paints for future use. But if you take plasticine instead of paints and give the artist, then you can’t get the desired color of plasticine by mixing plasticine (a laborious process). In this case, clay is inferior to paints.
Therefore, the use of the black box can be divided into two categories:
In the case of external libraries, “finished products” can be justified, but too big restrictions can lead programmers to the diabolical 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 enable it to be configured as much as possible and, accordingly, to expand its use.
Principles to consider when creating libraries, black boxes, for reused code:
PS: If the topic is interesting, then I will prepare examples of using the principles of OOSILA.
UPDATE: hidden box => black box
Encapsulation is an art, not just a black box. There is a problem - a code that cannot be fixed, redefined, changed, etc. in the same project where it is used. Everything must be configured, redefined, and modified. A universal soldier who is called in the right situation and he saves the world, and not the expectation of the birth of a new soldier. And the solution is not to fix the source code of the libraries, because This is a time-consuming process due to the simple lack of source. 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 there are encapsulation problemsbut they are solved. You can look at the black box as a finished product that is used to achieve the goal, and the material from which the form will be created to achieve the goal. You can give an example with an artist who uses paints for drawing and creates new paints, i.e. configures paints for future use. But if you take plasticine instead of paints and give the artist, then you can’t get the desired color of plasticine by mixing plasticine (a laborious process). In this case, clay is inferior to paints.
Therefore, the use of the black box can be divided into two categories:
- The finished product (relevant for companies that profit from the sale and support of the product, MS, Oracle, etc. For this reason, they provide classes that cannot be reconfigured)
- Intermediary (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, “finished products” can be justified, but too big restrictions can lead programmers to the diabolical 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 enable it to be configured as much as possible and, accordingly, to expand its use.
Principles to consider when creating libraries, black boxes, for reused code:
- Overriden. Make methods with an access statement so that you can override methods. (at least protected, use very rarely the access level is less than protected)
- Overload functions. A diverse signature of the same functions, reduce the number of parameters in methods
- Static is Evil. Static variables, functions evil, which must be replaced by ordinary variables and functions
- Control Instances. Do not create new objects without the possibility of overriding this creation. Do not use the new operator explicitly in your code, but use the setters methods for these objects, factories create objects, or create objects functions that are overridden
- Last Version is Evil. Do not use the final keyword for functions and classes. Allow overriding functions and classes
- Atomic Separate all logical units into small methods
PS: If the topic is interesting, then I will prepare examples of using the principles of OOSILA.
UPDATE: hidden box => black box