Poltergeist (computer programming): Difference between revisions

Revision as of 19:09, 18 March 2007

Latest revision as of 15:23, 24 October 2024

(41 intermediate revisions by 32 users not shown)

Line 1:

{{Short description|Computer programming object}}

Some may wonder why in the world I have destroyed your beloved article, but they know nothing. Some users fight for law and order in this massive encyclopedia, but I now proclame myslef on the side of mischief and mayhem. Why in the world would I want to support the side of destruction and madness? Good question my friends, good question. Perhaps I merely enjoy playing the villian, or neaby there is some method to my madness.

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 at 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 anti-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.

Nope.

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.

Reason, order, existance, what do these things mean? Where are they going? What is thier purpose? None that I can see. So if I were to bring choas to this world Wikipedia, it would not matter.

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

SEE YOU SOON!!!

-Q?

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

==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=0-471-19713-0 |chapter=Chapter 5: Software Development AntiPatterns |url-access=registration |url=https://archive.org/details/antipatternsrefa0000unse }}

==External links==

* [http://www.antipatterns.com/dev_cat.htm Development AntiPatterns]

[[Category:Anti-patterns]]

{{compu-prog-stub}}