Poltergeist (computer programming): Difference between revisions

Revision as of 22:16, 28 March 2021

Latest revision as of 15:23, 24 October 2024

(10 intermediate revisions by 8 users not shown)

Line 1:

{{Short description|Computer programming object}}

{{Refimprove|date=July 2007}}

In [[computer programming]], a '''poltergeist''' (or '''gypsy wagon''') is a short-lived, typically [[State (computer science)|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 1996at -the 1996 Object World West Conference:{{cn|date=October 2024}}

:"{{blockquote|As a [[Vardo (Romani wagon)|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 antipatternanti-pattern is poor object design." <!-- I think this is a quote -->}}

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 [[Vardo (Romani wagon)|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 antipattern is poor object design." <!-- I think this is a quote -->

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 [[Software design pattern|pattern]] such as [[model-view-controllermodel–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 (computerobject-oriented scienceprogramming)|inheritance]] or as a [[mixin]].

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]].

There have been proposed methods in detecting poltergeists in code for refactoring.<ref>{{cite book |last1=Al-Rubaye |first1=Samer Raad Azzawi |last2=Selcuk |first2=Yunus Emre |title=2017 8th IEEE International Conference on Software Engineering and Service Science (ICSESS) |chapter=An investigation of code cycles and Poltergeist anti-pattern |date=24–26 November 2017 |pages=139–140 |doi=10.1109/ICSESS.2017.8342882 |isbn=978-1-5386-0497-7 |chapter-url=https://ieeexplore.ieee.org/document/8342882/authors#authors}}</ref>

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

==See also==

* [[Anti-pattern]]

* [[Factory (object-oriented programming)]]

* [[YAGNI|YAGNI principle]]

==References==

Line 27 ⟶ 28:

{{Compcompu-sciprog-stub}}