Jump to content

Poltergeist (computer programming): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m upd link
Inner-Wikipedia link, cited sources, and added information.
Line 6: Line 6:
Sometimes, poltergeist classes are created because the [[programmer]] anticipated the need for a more complex architecture. For example, a poltergeist arises if the same method acts as both the ''client'' and ''invoker'' in a [[command pattern]], and the programmer anticipates separating the two phases. However, this more complex architecture may actually never materialize.
Sometimes, poltergeist classes are created because the [[programmer]] anticipated the need for a more complex architecture. For example, a poltergeist arises if the same method acts as both the ''client'' and ''invoker'' in a [[command pattern]], and the programmer anticipates separating the two phases. However, this more complex architecture may actually never materialize.


Poltergeists should not be confused with long-lived, state-bearing objects of a [[Software design pattern|pattern]] such as [[model–view–controller]], or tier-separating patterns such as [[business-delegate]].
Poltergeists should not be confused with long-lived, state-bearing objects of a [[Software design pattern|pattern]] such as [[model–view–controller]], or tier-separating patterns such as [[business delegate pattern]].


To remove a poltergeist, delete the class and insert its functionality in the invoked class, possibly by [[Inheritance (object-oriented programming)|inheritance]] or as a [[mixin]].
To remove a poltergeist, delete the class and insert its functionality in the invoked class, possibly by [[Inheritance (object-oriented programming)|inheritance]] or as a [[mixin]].

There have been proposed methods in detecting poltergeists in code for refactoring.<ref>{{cite journal |last1=Al-Rubaye |first1=Samer Raad Azzawi |last2=Selcuk |first2=Yunus Emre |title=An investigation of code cycles and Poltergeist anti-pattern |date=24-26 November 2017 |doi=10.1109/ICSESS.2017.8342882 |url=https://ieeexplore.ieee.org/document/8342882/authors#authors}}</ref>


==See also==
==See also==

Revision as of 08:27, 8 November 2023

In computer programming, a poltergeist (or gypsy wagon) is a short-lived, typically stateless object used to perform initialization or to invoke methods in another, more permanent class. It is considered an anti-pattern. The original definition is by Michael Akroyd 1996 - Object World West Conference:

"As a gypsy wagon or a poltergeist appears and disappears mysteriously, so does this short lived object. As a consequence the code is more difficult to maintain and there is unnecessary resource waste. The typical cause for this anti-pattern is poor object design."

A poltergeist can often be identified by its name; they are often called "manager_", "controller_", "supervisor", "start_process", etc.

Sometimes, poltergeist classes are created because the programmer anticipated the need for a more complex architecture. For example, a poltergeist arises if the same method acts as both the client and invoker in a command pattern, and the programmer anticipates separating the two phases. However, this more complex architecture may actually never materialize.

Poltergeists should not be confused with long-lived, state-bearing objects of a pattern such as model–view–controller, or tier-separating patterns such as business delegate pattern.

To remove a poltergeist, delete the class and insert its functionality in the invoked class, possibly by inheritance or as a mixin.

There have been proposed methods in detecting poltergeists in code for refactoring.[1]

See also

References

  1. ^ Al-Rubaye, Samer Raad Azzawi; Selcuk, Yunus Emre (24–26 November 2017). "An investigation of code cycles and Poltergeist anti-pattern". doi:10.1109/ICSESS.2017.8342882. {{cite journal}}: Cite journal requires |journal= (help)CS1 maint: date format (link)