When an object is allocated off the heap, ownership can be a problem. Who is responsible for deleting it?

The Interface/Implementation strategy of the DB Interface Module makes dealing with the heap unnecessary. The interface classes of the DB Interface Module consist only of a pointer to an implementation class instance and an invisible pointer to a virtual function table. The implementation is reference counted, so that when no further interface instances reference the given implementation instance, the implementation instance is automatically deleted. Because copy constructors and assignment operators are very efficient, there is little reason for your applications to allocate Interface Module classes off the heap, or to operate on pointers to Interface Module classes. Of course, you aren’t prevented from doing so, but it is unnecessary.

For example, suppose we require a class, each of whose instances corresponds to a single row of a database table. It might be handy to carry along a reference to the database holding the physical table:

Notice that we are able to embed an RWDBDatabase instance in each Part without incurring undue overhead. Similarly, our Part constructor is able to initialize the embedded RWDBDatabase instance by invoking the RWDBDatabase copy constructor, another low-overhead operation. It is unnecessary to declare a pointer to an RWDBDatabase anywhere, so it is unnecessary to do any explicit memory management of classes in the DB Interface Module. In fact, most of the API of the DB Interface Module is remarkably pointer-free.