Antipatterns of Design: Poltergeists

Original author: Alexander Shvets
  • Transfer
“I don’t know exactly what this class does, but I’m sure that it is important!”

Design patterns - typical solutions, have antipodes - typical design errors. Enough books have been written about design patterns, and only a few about antipatterns. We present to your attention a free translation of an article from the SourceMaking website that describes one of these antipatterns ( there are 14 of them in the Software Development Antipatterns section of the site ).

Name: Poltergeists (poltergeists)
Other names: Gypsy (gypsies), Proliferation of Classes (increase in the number of classes), Big DoIt Controller Class
Scale: application
Refactoring: Ghostbusting ( ghostbusting )
Reason: lack of understanding of OOP concepts, too lazy to think over class architecture

Note: the author of the translation in no way claims to be the design guru and therefore asks not to perceive the article with a touch of moralizing. The main goal of the article is a deeper understanding of the essence of the issue and, possibly, finding out how vital the described situation is.

Background


The antipattern under consideration under the name Gypsies was first introduced by Michael Akroyd at the Object World West conference in 1996. Ackroyd found the behavior of this antipattern similar to the nomadic life of gypsies who suddenly appear and then also suddenly disappear. In order to convey more information about its essence in the name of the antipattern, we chose another name: “Poltergeists”. These "restless ghosts" lead their own - isolated nightlife. This term better represents the concept of “peeking to do something” of this antipattern and at the same time preserves the metaphor “here they are, but they are no longer there” of the original name.

Among LISP programmers (as well as among others), there are developers who take pleasure in maximizing the use of the “side effects” of a number of functions of the programming language to perform key tasks in their system in an implicit way. Analysis and understanding of such systems is practically impossible and any attempt to reuse it often becomes meaningless.

Just as the use of “side effects” is an incorrect use of language tools, the appearance of poltergeist classes is also the result of misuse of design concepts.

Description


Poltergeists are classes with limited liability and a role in the system. Their effective life cycle is short. Poltergeists violate the harmony of software architecture, creating redundant (redundant) abstractions, they are overly confusing, difficult to understand and difficult to maintain.

This antipattern 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 temporarily to initiate some action in another, more permanent (with a longer lifetime) class. Ackroyd calls these classes Gypsy Carriages. Typically, such classes are thought of as controller classes that exist only to call methods of other classes, often in a predetermined sequence. Usually they are obvious, as their names often end with "_manager" , "_controller" .

The culprit in the emergence of the antipattern "poltergeist" is usually a novice architect who does not fully understand the concepts of object-oriented design. Poltergeist classes are poor architectural solutions for three key reasons:
  • they are optional and therefore uselessly spend 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 an object model.

Signs of the appearance and consequences of antipattern


  • Excessive navigation paths.
  • Bp e mennye Association ( approx .: hereinafter taken due ratio under the "association" of the UML ).
  • Stateless classes (containing only methods and constants).
  • Bp e mennye objects and classes (with a short lifetime).
  • Classes with a single method that is only intended to create or call other classes through temporary association.
  • Classes with method names in the "control" style, 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 right solution for all tasks. As one poster says: "There is no right way to make a mistake." For the problem under consideration, 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 requirements analysis stage (prior to object-oriented analysis) can also lead to problems similar to this antipattern.

Refactoring


The problem of poltergeists is solved by removing them from the class hierarchy. The “functions” they perform must be replaced. This is usually quite simple to do by making trivial adjustments to the architecture.

The key to the solution is to transfer the control actions of the poltergeist controller (which are encapsulated by it) into classes whose methods the poltergeist calls.

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 tan;
  • he has no condition;
  • is a temporary class that exists only to call other classes through temporary associations.

In this example, if we delete the poltergeist class, the remaining classes will lose the ability to interact, and there will also be no order in which the processes will run. Therefore, we need to place the possibility of interaction in the remaining hierarchy. Note that certain operations are added to each process in such a way that each class individually interacts and processes the results.

Related solutions


The “80% solution” discussed in the Blob antipattern looks very similar to the poltergeist antipattern. The presented class “coordinator” still controls the entire or greater functionality of the system and, as a rule, has many poltergeist properties.

Applicability to other scales and levels of the system


The antipattern occurs when developers also design how they implement the system (usually “by the seat of their pants” ), and may also arise as a result of omissions in building the system architecture.

As with most antipatterns of design, both the architectural and managerial levels play a key role in preventing and subsequently combating them. The appearance of antipattern is often recognized precisely from an architectural point of view, and through effective management it is worth considering this point of view immediately.

Managers should ensure that object-oriented architectures are evaluated by qualified architects at the earliest stage of their creation and regularly thereafter. This will avoid the mistakes of beginners like this antipattern. It’s better to pay the price of good architecture in advance.

Also popular now: