Object cesspool: Difference between revisions

Revision as of 18:50, 5 October 2005

Revision as of 18:52, 5 October 2005

Line 9:

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's 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.