Lesson plan
Poltergeist (computer programming)
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 at the 1996 Object World West Conference: A poltergeist can often be identified by its name; they often include words such as " ", " ", " ", " ", etc. in the name. 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.
Article summary
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 at the 1996 Object World West Conference: A poltergeist can often be identified by its name; they often include words such as " ", " ", " ", " ", etc. in the name. 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.
Key claims
No claims recorded.
Discussion questions
- Summarise the article in your own words. Which single claim would you verify first, and why?
- Which claim in this article is most likely to be revised as the sources update? How would you check its current status?
- If two sources disagreed about one of these facts, what would you need in order to trust one over the other?
Bibliography
No sources recorded.
Key claims and bibliography are generated from the same tracked claims and sources as the article page.