Poltergeist (computer programming): Difference between revisions
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 |
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
- ^ 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)
- Brown, William J. (1998). "Chapter 5: Software Development AntiPatterns". AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. New York, USA: John Wiley & Sons. ISBN 0-471-19713-0.
External links