Object cesspool: Difference between revisions

Revision as of 20:38, 5 October 2005

Revision as of 20:50, 5 October 2005

Line 7:

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 CreditCardProccessorCreditCardProcessor 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.