Content deleted Content added
fix typo |
fixed logical error. |
||
Line 5:
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, clients which receive a used object must receive an object which is an initialized state, 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 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 not 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 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.
| |||