|
#REDIRECT [[Object pool pattern#Pitfalls]]
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 new clients.
{{redirect category shell|{{R to section}}{{R from merge}}}}
Oftentimes, the afflicted software will yield unpredictable and sporadic results when performing operations that seem routine. This problem arises when used objects returned from the pool to a client which are in a state that is incompatible with the expected operation of 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.
Object pools are a useful construct for managing limited resources and reducing the amount of initialization necessary when a class is used very frequently. However, in an object cesspool, clients which receive a used object must receive an object which is an initialized state. Often enough a cesspool object will be in some state that was unexpected by the client program and will cause the client program to fail.
In C++ in particular, the original class programmer may have only placed the object cleanup code within the object's destructor prior to architecting the class so that it can be used within a pool. In that situation, the class deconstructor is only called when the object is torn down by the pool manager, and clients continue to recieve object instances which have unpredictable state.
For example, consider a programmer who writes a CreditCardPool class which return CreditCardProcessor objects. A client program needs to authorize a credit card, and it does so by retrieving a CreditCardProccessor 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.
| 