Introduction to Components: What is Component? Impact of C++
Dynamic Link Library (DLL) in simple is the definition of the exposed operations. The definitions include pointers/links to the actual code. The calling code (client code) is bound/linked to this definition and the DLL’s actual code is called in runtime using the pointers/links from the DLL definition.
In 90s (late 80s?), Object oriented methodology gain repute and become a standard in the main stream software engineering. Object oriented approach generally include four aspects; identity, classification, polymorphism and inheritance. Identity means that the data is grouped into discrete, distinguishable, entities called objects. Classification tells about grouping of same data structures and operations, called classes. Polymorphism is about the different behavior of the same operation on different classes and Inheritance is the sharing of data structures and operations among classes based on hierarchical relationships. C++ came into being to support the OO-methodology. People were able to use classes and access modifiers. These created confusion in the world of DLLs. (Should we expose private operations? Two operations with same name in two different classes? Etc)
The C/C++ compilers vendor invented name mangling. In the DLL definition; the name of the class is made part of the name of the exposed code definition. They decided to expose only the public operations/data structures. But what if we need to change the public operation/data structures in the class that implements the functionality being exposed in the DLL? The previously linked client code will become incompatible. The possible workout could be that we code a wrapper class aggregating the actual implementation class, the wrapper class simply exposes the required operations/data-structures and its responsibility is just to forward the calls to the actual implementation class. The implementation class can be updated; new public operations/attributes can be added. Naming is not the only problem, there are other issues like the memory layout of the data-structures (basic C/C++ or composite, like struct), argument passing mechanism (left to right? right to left, order of packing/unpacking?), stack maintenance responsibility (who will declare the memory for the argument, the caller? the callee?) and virtual function implementation approaches. (V-Table structures?)
The workout described earlier can work until the client code is compiled/linked using the compiler/linkers from the same vendor assuming that the same vendor will continue to offer the similar approach to all the above stated areas. This even can not be assured, as vendor may decide different approach to increase productivity or performance.
To solve such issues Component Object Model (COM) was proposed. This model make uses of Object oriented capabilities of the C++ and propose standards to target the issues stated above. (There might be others, I am unaware of) DLL/SO concept is also extended, now one can expose collection of operations and data-structures, called interface, that gives object oriented flavor to the DLL developers.
What is Component? A component in the given context of some architecture is an independent and replaceable software unit. C++ class, Java bean, VB class/module, Database in some DBMS is all examples of software component. COM is the model that defines the approach and proposes standards about sharing the software component in such a manner, that the code can be re-used even if different compilers/linkers are used. The component code can be in any language that the runtime platform supports, and the component can even be reused on different platforms (in theory at least, though COM only became popular on Windows)
Stay tuned with my COM posts, in next post, I will be talking about the technical aspects of the COM