Thoughts on Teaching COM

Sometimes I keep thinking: we use COM-related technology every day (no doubt about it — Windows is built with COM, VB6, ASP, JScript are all COM underneath), but many people find COM hard to learn. I wonder if COM teaching has gone down the wrong path. C++ has its object model, COM has its object model, .NET and Java each have their own object models (though .NET and Java’s are transparent to programmers — MS and Sun don’t need or want programmers to understand them). But because some features of COM’s object model resemble C++’s object model, most textbooks use C++ to explain COM principles (“COM Essence,” “COM Technology Insider” are the “culprits”). Principles are important, but this makes the barrier to entry very high — you must deeply understand C++ internals and object models to grasp what those books are saying. And even after understanding, many still can’t write a usable COM component.

I wonder if COM understanding could also go from perceptual to rational — like how we use Windows without understanding processes, threads, virtual memory, MMU, scheduling algorithms; or how we send emails every day without knowing POP3 or SMTP protocols. Could we teach COM not starting from C++, but using VB6, ATL, or even Visual J++ to write COM components first — or just use existing COM components like DX and ADO in VB? Then gradually understand COM-based technologies like ActiveX, DirectX, OLE, and finally explain COM principles, its pros and cons, similarities and differences with C++. I don’t think you need to thoroughly understand IClassFactory, AddRef, Release, QI, IDispatch, CoCreateInstanceEx, IMoniker, SysAllocString… to “know” COM. Just like how we use J2SE, J2EE without knowing whether Java’s GC uses Mark&Sweep, or Java’s object memory layout, or how .class file metadata describes each class and implements Reflection.