>Thanks, Jim. This is what I told my colleague, who is currently in charge of Update application, but she told me, that otherwise the process would be much slower, since oPost would be needed to instantiate each time again (it has exessive Init and Destroy methods).
>
>Anyway, I'll see her on Monday and will use your arguments in addition to mine.
>
Nadya,

No oPost doesn't have to be created and destroyed every time, it has to be promoted to a higher level in the overall project so it already exists and doesn't get destroyed until it is no longer needed.

One design that could handle this situation is to create a utility object that is created at the highest level of the system. The job of that object is to create utility objects for other systems lower in the heirarchy. That object could have a method named GetUtility() that is called by any subsystenm that needs a utility like oPost. The Utility object would receiver the request and check to see if the requested object already exists, if it does the method returns an object reference to the utility. If not the GetUtility() method creates the object.

The Utility manager object could use an array property to hold the utility objects where the array has multiple columns one for the object reference and the others for identifying the object.

With this type of design you solve the problem of managing the destruction adn clean up of oPost, but you also solve all of the other similar problems that other subsystems encounter.

If you driive the utility manager object from a metadata table it becomes really easy to add a new utility object to whole system. Just create a class definition and add a record to the metadata.