Briefly about abstractions

It so happens that the project comes to a standstill, and its further development becomes impossible. It is not rare that the failure of such an architecture, which was laid down at the beginning of development, becomes the cause of such a failure. Or do we have to observe disputes about which of the “two chairs” is better, or maybe even participate and sincerely not understand how an opponent can think like that !?

Then try not to understand much about the abstractions, where they come from and what to do with them.

According to Wikipedia, Abstraction is a theoretical generalization as a result of abstraction. In its turn, abstraction is a distraction in the process of cognition from non-essential aspects, properties, connections of an object (object or phenomenon) in order to single out their essential, regular features.

From the definition we can conclude that only meaningful can be an abstraction. At the same time, perception is only a projection of the real world. It turns out that all thoughts about the real are reflections on our real models.

Abstractions form hierarchies, and can be identified with both private entities and unite similar entities into higher-level abstractions.

Abstractions in the mind

In addition to the prism of perception, our models are subjected to another distortion: real entities are extremely complex and have different aspects and parameters. When thinking or talking about something, there is always a context in which the model exists. And sometimes it happens that the interlocutors have a different context. And to top it off, the presence or absence of experience (global) leads to an even greater change in our models in accordance with this experience. As a result, two different people may have a very different perception of the same entities of the real world.

It turns out that each person constantly deals with abstractions, it remains to learn how to see and manage them clearly. You can put forward the thesis that the program code is a simulation of thinking based on formal abstractions. Therefore, in my opinion, software development is one of the best simulators for pumping abstract thinking.

Abstractions in development

Software interfaces are perhaps the most obvious formal abstraction. All unnecessary is cut off and only “what it does” without “how it does” remains.
By implementing the interface, we create a more realistic model of behavior or interaction, which can already answer the question "how." By combining the interfaces with each other, we can create a common code architecture. With proper skill and skill, the architecture created in this way will maintain its structure in the future. While implementations of composite interfaces may change beyond recognition.

This architecture simplifies some points in the work. Unit testing is reduced to writing test implementations of "neighboring" abstractions and test methods that compare input and output. Module isolation allows you to safely refactor. Moreover, if the refactoring was unsuccessful and everything broke, then only one module would have to be rolled back. A rather abstracted module can be used for similar, but different tasks. In this case, one poor implementation will not affect the work of others - shit isolation.

Abstractions are no longer needed

There are no perfect solutions, and abstractions are not so smooth. First, abstractions are subjective, they can cause controversy about where one begins and the other begins. There is also the problem of excessive abstraction, when each type and tonality of a sneeze creates its own abstraction. Secondly, this approach increases the complexity of the code by adding new entities and new levels of hierarchy. I am sure that there will be more shortcomings of this approach, some of them will be subjective, some situational, but there will be

There must be a balance in everything. For myself, I brought the following memo.

• If a large and important module is written, it is better to unlink it.
• If the module is used a lot and / or in different places - it is better to hide it behind the abstraction.
• If the module should be distributed as a separate library, it is better to use abstractions.
• If it is possible to change the algorithms or interaction paths, it is better to implement the interaction of abstractions.
• If a class is used in another class and nowhere else, you can think about combining them or leaving them as they are.
• If this is a small "one-time" task - it is better not to bother with its complication.
• If this is a module that most likely will never change - you can display its interface and better leave it as it is.

Total

Abstractions are a tool embedded in our consciousness, like any other, they have their pros and cons, but knowing the alternatives only helps to find the best way.