Poltergeists
JaninaVoigt (Talk | contribs) (New page: A poltergeist (or gypsy wagon) is a temporary and usually stateless object that is used to initialize or call methods of a more permanent object. It is usually very short lived and appears...) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Bertrand Roussel) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 17: | Line 17: | ||
==Related design heuristics== | ==Related design heuristics== | ||
*[[Keep related data and behavior in one place]] | *[[Keep related data and behavior in one place]] | ||
| + | |||
| + | {{Design Anti-patterns}} | ||
| + | [[Category: Anti-Patterns]] | ||
Latest revision as of 03:22, 25 November 2010
A poltergeist (or gypsy wagon) is a temporary and usually stateless object that is used to initialize or call methods of a more permanent object. It is usually very short lived and appears and disappears quickly.
Poltergeists can sometimes be identified by their names, which often includes the phrases manager or controller.
Poltergeists can be easily removed by deleting the poltergeist class and inserting its behavior into the class that it calls.
Example
Imagine that we are building a baking system and have an account class to store information about accounts. Every time we need to create an account or make a transaction, we create an AccountManager object for that account which takes care of that by calling methods on the Account class.
In this case, AccountManager objects are poltergeists and appear and disappear as necessary. Instead, the functionality should be moved into the Account class and those methods should be called directly by clients.
Liabilities
- Code can be difficult to understand and maintain since it can be hard to figure out where poltergeists come from and what they do.
- Resources are wasted because unnecessary objects have to be created and destroyed.
Related design heuristics
