Effective COM

Here are my crib notes for "Effective COM: 50 Ways to Improve your COM and MTS-based Applications" by Don Box, Keith Brown, Tim Ewald, and Chris Sells, from Addison Wesley, 1999.

Remember how Meyer's "Effective C++" book stopped you from using about two-thirds of the gimmicks explained in earlier books? "Effective COM" will stop you from imitating at least 90% of the COM you see elsewhere. Only after reading this book did I feel I had any hope of achieving good style with COM.

§    Lessons

§    Editorial

This book confirms the long-standing belief that MS development tools encourage fragile and unmaintainable code. The code may still compile, but it won't be easy to upgrade or integrate with next year's code. MS will constantly change their recommended patterns, frameworks, and developer tools. The book's epilogue says "Distrust your tools. The COM group produces COM, and various tool groups at Microsoft proceed to butcher it." Remember, clean maintainable code is not necessarily in Microsoft's interest.

You should be able to justify every line typed into your COM code, without a wizard's guidance. Find a safe core subset of COM and don't use clever tricks just because they are explained in every other COM book. If you stick to the safe subset, you may not have to rewrite current code every time you reuse it.

This book, and Don Box's previous book "Essential COM", unfortunately maintain the pretense that COM is a binary standard, independent of language or platform. COM is is none of these. COM is a C++ specification for Microsoft compilers on Microsoft operating systems. With any language other than C++ you are incompatible with the design of COM. With any other compiler or platform, you can forget about binary compatibility. The binary layout of C++ vtables is not a standard. You can use parts of COM in other Microsoft languages, but those languages introduce hacks that look horrible in C++.

Stick to C++ when implementing interfaces for other Microsoft developers, and stick to the cleanest possible C++ style. If you want Java, GNU C++, or other non-Microsoft languages, then use portable connections like sockets or JNI to talk to COM proxies and clients. (J++ isn't Java, and it isn't meant to be maintainable.)

The purpose of COM is to introduce components to each other, not to dictate how they interact or exchange data. The COM specification emphasizes, "COM, like a traditional system service API, provides the operations through which a client of some service can connect to multiple providers of that service in a polymorphic fashion. But once a connection is established, COM drops out of the picture. COM serves to connect a client and an object, but once that connection is established, the client and the object communicate directly without having to suffer overhead of being forced through a central piece of API code..."

Bill Harlan, March 1999

Return to parent directory.