In computer programming, an object cesspool is an antipattern that occurs whenever an object pool contains stateful class instances that were used by a client, but the used objects are not returned to a useable state when released back to the pool and/or the evidence of the use of the object is not reset prior to returning the object to a new client.
Oftentimes, the afflicted software will yield unpredictable and sporadic results when performing operations that seem routine. This problem arises when a used object returned from the pool to a client is in a state that is incompatible with that expected by the client. The problem is also more apparent in object pools which contain class instances that are very complex as opposed to simpler classes with few properties and/or methods.
An object pool is a useful construct for managing limited resources and reducing the amount of initialization necessary when a class is used very frequently. However, clients which receive a used object must receive an object which is in an initialized state. That is, they should presume that the object is ready to be used after the constructor runs or the object is returned from a class factory which manages the pool. Often enough a cesspool object will be in some state that was unexpected by the client program and that will cause the client program to fail.
In C++ in particular, the original class programmer may have placed the object cleanup code only within the object's destructor, making it unsuitable for use in a pool. In that situation, the object cleanup code is not executed before the pool manager returns an instance to the client, and the client recieves an object instance which has unpredictable state.
For example, consider a programmer who writes a CreditCardPool class which returns CreditCardProcessor objects. A client program needs to authorize a credit card, and it does so by retrieving a CreditCardProcessor from the pool. However, the program gets a CreditCardProcessor object which was used by another program and was released without clearing its state and contains information about another account.
As the program runs on this "dirty" instance, the card authorization declines. However, when the ApprovalCode field is checked, it has a value that shows the card was approved, but this was an approval code for someone else's account on a previous use of the object... not the current instance the client program thinks it is.
The typical fix for this situation is to mandate a "clean" method on each interface type the object pool supports. Objects are then cleared of state just prior to returning instances to clients.