Poltergeist (computer programming): Difference between revisions

Revision as of 16:00, 26 October 2010

Latest revision as of 15:23, 24 October 2024

(22 intermediate revisions by 19 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}}

{{POV|date=December 2007}}

:"{{blockquote|As a [[Vardo_%28Romani_wagon%29Vardo (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 -->}}

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

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_%28Romani_wagon%29|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 -->

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 [[Commandcommand pattern]], and the programmer anticipates separating the two phases. However, this more complex architecture may actually never materialize.

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

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-Delegatebusiness delegate pattern]].

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.

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==

<references/>

*{{cite book |last=Brown |first=William J. |title=AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis |year=1998 |publisher=John Wiley & Sons |___location=New York, USA |isbn=04711971300-471-19713-0 |chapter=Chapter 5: Software Development AntiPatterns |url-access=registration |url=https://archive.org/details/antipatternsrefa0000unse }}

==External links==

Line 25 ⟶ 27:

[[Category:Anti-patterns]]

{{Compcompu-sciprog-stub}}