Antipattern design: Poltergeists
“I don’t know exactly what this class is doing, but I’m sure this is important!”
Design patterns — typical solutions, have antipodes — typical design errors. Enough books have been written about design patterns, and only a few about anti-patterns. A free translation of an article from the SourceMaking site describing one of these anti-patterns is presented to your attention (there are 14 in total on the site in the Software Development Antipatterns section).
Title: Poltergeists (Poltergeist)
Other names: Gypsy (Gypsy), Proliferation of Classes (increase in the number of classes), Big DoIt Controller Class
Scale: application
Refactoring: Ghostbusting (Ghostbusters)
The reason for the appearance: lack of understanding of the concepts of OOP, too lazy to think over the architecture of classes
Note: by no means does the author of the translation claim to be a design guru and therefore asks not to take the article with a touch of moralizing. The main goal of the article is a deeper understanding of the essence of the question and, possibly, clarification of how vital the situation described is.
The considered anti-pattern under the name "Gypsies" was first introduced by Michael Akroyd at the Object World West conference in 1996. Aroyd found the behavior of this anti-pattern similar to the nomadic life of the Gypsies, who suddenly appear and then also suddenly disappear. In order to convey more information about its essence in the name of the anti-pattern, we chose another name: “Poltergeist”. These "restless ghosts" lead their own - a separate nightlife. This term better represents the concept of “peek into something to do” of this anti-pattern and at the same time retains the metaphor “here they are and here they are no longer” of the original name.
')
Among LISP programmers (as well as among others), there are developers who enjoy the maximum use of the “side effects” of a number of programming language functions to accomplish key tasks in their system in an implicit way. The analysis and understanding of such systems is practically impossible and any attempt to reuse often becomes meaningless.
Exactly how the use of "side effects" is an incorrect use of language means, and the emergence of poltergeist classes is the result of improper use of design concepts.
Poltergeist are classes with limited liability and role in the system. Their effective life cycle is short. Poltergeists violate the harmony of software architecture, creating redundant (redundant) abstractions, they are overly complicated, difficult to understand and difficult to maintain.
This anti-pattern is typical in situations where designers are familiar with the modeling process but do not have sufficient experience in creating object-oriented architectures. In their architecture, it is possible to identify one or more poltergeist classes that appear at a time to initiate an action in another, more permanent (with longer lifetime) class. Akroyd calls these classes "Gypsy wagons." Typically, such classes are thought of as controller classes, which exist only for calling methods from other classes, often in a predefined sequence. Usually they are obvious, as their names often end with "_manager" , "_controller" .
The culprit for the appearance of the poltergeist anti-pattern is usually a novice architect who does not fully understand the concept of object-oriented design. Poltergeist classes are bad architectural solutions for three key reasons:
The problem of poltergeists is solved by removing them from the class hierarchy. The “functions” they perform must be replaced. This is usually fairly easy to do by making trivial adjustments to the architecture.
The key in the solution is to transfer the poltergeist controller's control actions (which are encapsulated in it) into classes whose methods are called by the poltergeist.
For a clearer understanding of the pattern, consider the example in the figure.
We see that the Peach Canner Controller class is a poltergeist because:
In this example, if we remove the poltergeist class, then the remaining classes will lose the ability to interact, and there will be no order of execution of the processes left. Therefore, we need to place the opportunity for interaction in the remaining hierarchy. Notice that certain operations are added to each process in such a way that each class separately interacts and processes the results.
The "80% solution" discussed in Blob's anti- pattern looks very much like the poltergeist pattern. The presented class "coordinator" still controls all or more of the functionality of the system and, as a rule, has many poltergeist properties.
An anti-pattern occurs when developers design as well as how they implement the system (usually “by the seat of their pants” ), and may also arise as a result of omissions in the construction of the system architecture.
As is the case with most design anti-patterns, both architectural and managerial levels play a key role in the prevention and subsequent control of them. The appearance of the anti-pattern is often recognized precisely from an architectural point of view, and through effective management, this point of view should be taken into account immediately.
Managers need to ensure that object-oriented architectures are evaluated by qualified architects at the very early stage of their creation and regularly later. This will avoid the mistakes of newbies like this anti-pattern. It is better to pay the price of good architecture in advance.
Design patterns — typical solutions, have antipodes — typical design errors. Enough books have been written about design patterns, and only a few about anti-patterns. A free translation of an article from the SourceMaking site describing one of these anti-patterns is presented to your attention (there are 14 in total on the site in the Software Development Antipatterns section).
Title: Poltergeists (Poltergeist)
Other names: Gypsy (Gypsy), Proliferation of Classes (increase in the number of classes), Big DoIt Controller Class
Scale: application
Refactoring: Ghostbusting (Ghostbusters)
The reason for the appearance: lack of understanding of the concepts of OOP, too lazy to think over the architecture of classes
Note: by no means does the author of the translation claim to be a design guru and therefore asks not to take the article with a touch of moralizing. The main goal of the article is a deeper understanding of the essence of the question and, possibly, clarification of how vital the situation described is.
Background
The considered anti-pattern under the name "Gypsies" was first introduced by Michael Akroyd at the Object World West conference in 1996. Aroyd found the behavior of this anti-pattern similar to the nomadic life of the Gypsies, who suddenly appear and then also suddenly disappear. In order to convey more information about its essence in the name of the anti-pattern, we chose another name: “Poltergeist”. These "restless ghosts" lead their own - a separate nightlife. This term better represents the concept of “peek into something to do” of this anti-pattern and at the same time retains the metaphor “here they are and here they are no longer” of the original name.
')
Among LISP programmers (as well as among others), there are developers who enjoy the maximum use of the “side effects” of a number of programming language functions to accomplish key tasks in their system in an implicit way. The analysis and understanding of such systems is practically impossible and any attempt to reuse often becomes meaningless.
Exactly how the use of "side effects" is an incorrect use of language means, and the emergence of poltergeist classes is the result of improper use of design concepts.
Description
Poltergeist are classes with limited liability and role in the system. Their effective life cycle is short. Poltergeists violate the harmony of software architecture, creating redundant (redundant) abstractions, they are overly complicated, difficult to understand and difficult to maintain.
This anti-pattern is typical in situations where designers are familiar with the modeling process but do not have sufficient experience in creating object-oriented architectures. In their architecture, it is possible to identify one or more poltergeist classes that appear at a time to initiate an action in another, more permanent (with longer lifetime) class. Akroyd calls these classes "Gypsy wagons." Typically, such classes are thought of as controller classes, which exist only for calling methods from other classes, often in a predefined sequence. Usually they are obvious, as their names often end with "_manager" , "_controller" .
The culprit for the appearance of the poltergeist anti-pattern is usually a novice architect who does not fully understand the concept of object-oriented design. Poltergeist classes are bad architectural solutions for three key reasons:
- they are optional and therefore waste resources every time they "appear";
- they are inefficient because they use redundant navigation paths;
- they interfere with proper object-oriented design, since they unnecessarily load the object model.
Signs of the appearance and effects of anti-pattern
- Redundant navigation paths.
- Temporary associations ( note: hereinafter, under the "association", the relation is a connection from UML ).
- Classes without state (containing only methods and constants).
- Temporary objects and classes (with a short lifetime).
- Classes with a single method that is only intended to create or call other classes through a temporary association.
- Classes with “control” style method names, such as start_process_alpha .
Typical causes
- Lack of object-oriented architecture (the architect does not understand the object-oriented paradigm).
- Wrong choice of the way to solve the problem. Contrary to popular opinion, an object-oriented approach is not necessarily the only correct solution for all problems. As one poster says: "There is no right way to make a mistake." For the problem in question, this means that if the object-oriented approach is not the right choice, then there is no right way to implement it.
- Assumptions about the application architecture at the stage of requirements analysis (prior to object-oriented analysis) can also lead to problems like this anti-pattern.
Refactoring
The problem of poltergeists is solved by removing them from the class hierarchy. The “functions” they perform must be replaced. This is usually fairly easy to do by making trivial adjustments to the architecture.
The key in the solution is to transfer the poltergeist controller's control actions (which are encapsulated in it) into classes whose methods are called by the poltergeist.
Example
For a clearer understanding of the pattern, consider the example in the figure.
We see that the Peach Canner Controller class is a poltergeist because:
- has redundant navigation paths to all other classes in the system in question;
- all his associations are tanzivic;
- he has no state;
- is a temporary class that exists only to call other classes through temporary associations.
In this example, if we remove the poltergeist class, then the remaining classes will lose the ability to interact, and there will be no order of execution of the processes left. Therefore, we need to place the opportunity for interaction in the remaining hierarchy. Notice that certain operations are added to each process in such a way that each class separately interacts and processes the results.
Related solutions
The "80% solution" discussed in Blob's anti- pattern looks very much like the poltergeist pattern. The presented class "coordinator" still controls all or more of the functionality of the system and, as a rule, has many poltergeist properties.
Applicability to other scales and levels of the system
An anti-pattern occurs when developers design as well as how they implement the system (usually “by the seat of their pants” ), and may also arise as a result of omissions in the construction of the system architecture.
As is the case with most design anti-patterns, both architectural and managerial levels play a key role in the prevention and subsequent control of them. The appearance of the anti-pattern is often recognized precisely from an architectural point of view, and through effective management, this point of view should be taken into account immediately.
Managers need to ensure that object-oriented architectures are evaluated by qualified architects at the very early stage of their creation and regularly later. This will avoid the mistakes of newbies like this anti-pattern. It is better to pay the price of good architecture in advance.
Source: https://habr.com/ru/post/217847/
All Articles