|
<!-- End of AfD message, feel free to edit beyond this point -->
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 clientsclient.
Oftentimes, the afflicted software will yield unpredictable and sporadic results when performing operations that seem routine. This problem arises when a used objectsobject returned from the pool to a client which areis in a state that is incompatible with thethat expected operation ofby 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.
ObjectAn poolsobject arepool 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 only placed the object cleanup code only within the object's destructor, prior to architecting the class so thatmaking it canunsuitable notfor beuse used withinin a pool. In that situation, the classobject deconstructorcleanup code is onlynot calledexecuted whenbefore the objectpool ismanager tornreturns downan byinstance to the pool managerclient, and clientsthe continueclient torecieves recievean object instancesinstance which havehas unpredictable state.
For example, consider a programmer who writes a CreditCardPool class which returnreturns 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.
| 