Object cesspool
m |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Stephen Fitchett) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | An object pool is a set of initialized objects that can be used and reused by clients rather than having to create and destroy objects every time. A client can request an object from the pool, use it and then return it. Object pool is a design pattern. | + | An object pool is a set of initialized objects that can be used and reused by clients rather than having to create and destroy objects every time. A client can request an object from the pool, use it and then return it. [[Object pool]] is a design pattern. |
Object pooling can increase performance when object instantiation is expensive, common and there are few objects in use at any one time. It is therefore often used for database of socket connections. However, in some cases object pooling can decrease performance. | Object pooling can increase performance when object instantiation is expensive, common and there are few objects in use at any one time. It is therefore often used for database of socket connections. However, in some cases object pooling can decrease performance. | ||
| Line 15: | Line 15: | ||
==Liabilities== | ==Liabilities== | ||
*Strange behavior and bugs if parts of the object that are important for the behavior of the object are not reset. | *Strange behavior and bugs if parts of the object that are important for the behavior of the object are not reset. | ||
| + | |||
| + | == See also == | ||
| + | * [[Flyweight pattern]] is a pattern that uses an object pool (and a strategy for avoiding it becoming a cesspool). | ||
| + | |||
{{Design Anti-patterns}} | {{Design Anti-patterns}} | ||
[[Category: Anti-Patterns]] | [[Category: Anti-Patterns]] | ||
Latest revision as of 03:21, 25 November 2010
An object pool is a set of initialized objects that can be used and reused by clients rather than having to create and destroy objects every time. A client can request an object from the pool, use it and then return it. Object pool is a design pattern.
Object pooling can increase performance when object instantiation is expensive, common and there are few objects in use at any one time. It is therefore often used for database of socket connections. However, in some cases object pooling can decrease performance.
Object cesspool is an anti-pattern which occurs when the state of the objects returned to the pool is not reset. If another client is then given the object whose state has not been reset, this can lead to bugs and program crashes.
It is particularly important to reset the fields of an object that have a significant influence on the behavior of the object.
Example
Imagine that we are writing a website which people can connect to using a web browser. Our web application needs to manage the incoming client connections and store the state of a client's session using the Session class. Because these sessions are expensive to instantiate, we use an object pool. Every time a client connects to the website, they are assigned a Session variable from the object pool. When they leave our site, the Session object is returned to the pool.
Our Session object may store information about the login status of the user and their history. If we do not remove this information from the object before returning it to the pool (for example set the login status back to not logged in) this will cause strange behavior when the object is reused by another client.
Liabilities
- Strange behavior and bugs if parts of the object that are important for the behavior of the object are not reset.
See also
- Flyweight pattern is a pattern that uses an object pool (and a strategy for avoiding it becoming a cesspool).
| Design anti-patterns | |
|---|---|
|
Anemic Domain Model | BaseBean | Call super | Circle-ellipse problem | Circular dependency | |
