22.2. Skin Selection

As we've mentioned earlier, one of the uses of bolt-ins is to finish off an incomplete class. Microsoft's Active Template Library (ATL) framework provides a number of examples of this. You define your class, which inherits from one or more COM interfaces, but do not define your reference-counting boilerplate. Specifically you do not implement the pure virtual methods of IUnknown (see section 19.8). Your class is, therefore, an abstract class, and you cannot instantiate instances of it.

However, you can define composite types, using one of ATL's predefined bolt-ins—CComObject, CComAggObject, CComObjectStack, and so on—or one of your own, and it is this composite type that is instantiated and that handles the IUnknown method implementations for us.

class MyServer


  : public IMyServer


  , public . . .


{};





new MyServer;             // error –  abstract type


new CComObject<MyServer>; // Ok; make me a normal COM object





MyServer                  ms1; // error – abstract type


CComObjectStack<MyServer> ms2; // Ok; make me a stack COM object

Hence, bolt-ins are a way of applying functionality to partially defined types, for example, implementing an interface. This means that the implementation of certain parts can be abstracted and generalized into a suite of related bolt-ins, which allows design decisions to be delayed and/or revised without the need for any (significant) coding effort. Not only does this help with the flexibility and reusability of software components, but it allows designs to be fixed at a later stage in the development process, which means that external change can be accommodated [Beck2000] at lower cost: a kind of software utopia.

Naturally this mechanism lends itself to the overriding of any virtual functions, not just those for which a vtable entry does not yet exist. Skinning completes abstract classes and/or changes the nature of concrete polymorphic classes. Next we'll look at the modification of non-virtual functionality.