COM and OO Modeling

Source: otug@rational.com
Date: 24-Sep-98

Problem: COM is Microsoft's component technology, and it does not support implementation inheritance. How should this fact affect OO modeling techniques used with COM?

Mark Rodgers explained how to emulate implementation inheritance using COM:

You can use inheritance of implementation as long as you use non-COM mechanisms to do so. For example, it is perfectly acceptable to use normal C++ inheritance between one class and another, especially if they are in the same package. The derived class usually just supports more interfaces, although it could also/instead provide alternative implementations for operations in an ancestor's interface.

In ATL, the COM_INTERFACE_ENTRY_CHAIN macro is used to append an ancestor's interface map to your own.

We use this to implement hierarchies like this:

  +----------+
  | Widget   |--------O
  +----------+     IWidget
       A
       |
+----------------+
| SpecialWidget  |-------O
+----------------+   ISpecialWidget

Widget just implements IWidget whereas SpecialWidget implements both interfaces and may override Widget's IWidget implementations.

You can even do the whole OO thing and make Widget an abstract class.

This hybrid approach of using COM across package/layer boundaries and using normal C++ within a package/layer works very well.

harmony2@swbell.net showed how this technique can be used during the development process:

[...] look at COM [...] as just a way to externalize interfaces.

I use interfaces in all of my code, not just stuff that uses COM. So I always draw my initial class diagrams with classes, interfaces, inheritance, aggregation, etc. If I know that some chunk of behavior will have to be implemented as a COM component, I make sure it has an interface. Other interfaces pop up as they are discovered. One of my favorite ways to build code is with inheritance trees made entirely out of interfaces. It isn't always the right thing to do, but it simplifies a lot of problems that are hard to predict.

I think early prototypes should leave out the COM stuff (if possible) and see if the ideas work. VC's COM support is cumbersome. Early in a design, I need the ability to make drastic architectural changes. I can't afford to wrestle with class wizard every time I change an interface.

If you've used interfaces throughout your analysis and design, slicing the code up into COM components is just a matter of identifying which chunks will be replaced and which chunks should stick together. Promote the C++ interfaces (abstract classes) to COM interfaces. The class diagrams shouldn't really change. The DLLs can be shown on component diagrams, along with the COM interfaces they expose and depend on.

More Info:

Microsoft, COM Technical Overview

Crispin Goswell, The COM Programmer's Cookbook

Don Box, Charlie Kindel, Grady Booch, Essential COM