Object cesspool: Difference between revisions

Revision as of 20:29, 5 October 2005

Revision as of 20:38, 5 October 2005

Line 3:

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