COM and COM+ are the hot new buzzwords coming from Microsoft. This is the first in a series introducing COM. COM is based on Object-Oriented Program concepts, so a brief discussion of OOP is required before exploring COM.
The history of programming has been a process of inventing ways of breaking problems into manageable portions. Early programming was Unstructured Programming; Code was written in one monolithic block. As programs grew larger, it became necessary to break up the program into easier to manage units: this was Procedural Programming. This created a new problem: it was difficult to understand the flow of a program with numerous arbitrary jumps to sub-procedures. Hence the introduction of Structured Programming, which imposed rules and a commonly agreed structure to the flow of programs. This was a huge success. It became possible to write huge programs of great complexity and functionality. The Client-Server revolution of the late eighties and nineties was built on structured programming.
However, the success of Structured programming would be its downfall. Customers were impressed by the results of structured programming and demanded more features. More features meant more complexity. Programmers have always dealt with the problem of complexity in the same way: by breaking up the problem into manageable bits. A more efficient and reliable way of doing this was needed: OOP.
Object Oriented Programming seeks to break programs into discrete, self-contained modules. The advantage of modularity will become obvious as we look at the main principles of OOP. OOP is built on three main principles: Encapsulation, Polymorphism and Inheritance.
Let me try to explain these concepts using some simple examples. Supposing you wanted to build a car. One way to go about it would be to go to your local hardware dealer, order a one-ton steel block and carve it into a car. Of course, if you made a mistake carving say, the hubcap, you'd have to chuck the entire car. So obviously, a better approach would be to make individual bits: a hubcap, a steering wheel, a carburetor and so on. If you made a mistake on one piece, you just need to fix that bit. This is modularity.
To speed up your work you hire two more guys to build parts along with
you. One guy keeps coming to you and saying things like, "I'm using
No3 gauge screws to connect the feeblestat to the doohickey. So you should
use 'em too. I use whatchamacallits instead of thingamabobs so you gotta
adjust for that." The other guy comes along and says, "I finished
this bit. Connect a pipe here and it'll work fine." After a week of
this, you can't take it any more and you fire the first guy. The point is
that the second guy's modules are self-contained. Since you don't need to
know how it works to use it, you can concentrate on making the entire car
instead of worrying about thingamabobs and doohickeys. And if your assistant
improves his module and it uses the same pipe connection then you don't
need to change a thing to use it. This is what is meant by encapsulation.
Objects in your program hide the details of how they work. They present
an Interface, which is not dependent on their implementation. Thus changes
or improvements in one module do not affect the rest of the application.
You hear one day that the factory next door mass-produces doohickeys. Their
doohickey does almost everything that you want. So you buy it, make a few
changes, and use it in your car. This is Inheritance. There are two benefits
to this. Firstly, the obvious benefit of reuse. Why write new code for just
slight changes to old code. But you also can't just change old code - it
may break something else in your program. So inherit the old behavior and
make the required changes to it in a new, child object. The second, more
important result is that your interface is consistent with the previous
type of object. It would be irritating if you decided to buy a larger car
and then found out that it was steered with a joystick instead of a steering
wheel. This concept of keeping a consistent interface brings me to polymorphism.
Your car is a tremendous success, so you decide to make cars for a living. You hire a bunch of sheet-metal workers, painters, assemblers and so on. Unfortunately, after you hire them you find out that the sheet-metal workers speak Greek, the painters Japanese and the assemblers just prefer a boot in the backside to start working. Slapping yourself on the forehead, you fire the whole lot of them and hire a bunch of Malayalees who never work but at least understand what you say when their labor union calls you for negotiations to end the strike. The point is "simble"; the different objects: sheet-metal workers, painters, assemblers and so on may have completely different behavior but they should present a common interface. Thus, a higher level object can use a common routine to initiate the function of each object. That is, to use our analogy, a foreman can go each worker and shout, "Work!" and be assured that each worker will perform his respective function. This is the concept of Polymorphism.
In future issues, we will see the application of these concepts to COM and COM+