Poltergeists
m (Reverted edits by Ebybymic (Talk); changed back to last version by Bertrand Roussel) |
|||
| Line 5: | Line 5: | ||
Poltergeists can be easily removed by deleting the poltergeist class and inserting its behavior into the class that it calls. | 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. | 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. | 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== | ==Liabilities== | ||
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
