Welcome to weblogs.com.pk Sign in | Join | Help

Introduction to Components: Background

Number of paradigms and methodologies has been offered to help developers and software vendors in their software engineering activities. The main theme and centre point of these methodologies have been code re-usability. The same idea is even present in the form of Abstraction and Inheritance in the Object Oriented Programming (OOP) methodology, the latest and widely accepted approach to date.

In the following paragraphs, I will be using the term third party for the third party vendor as well as some third party team/person who is not directly involved.

The code reusability in the traditional approaches have been addressed in two ways, (a) providing the complete source code of the module that is included and compiled while developing some software piece and by (b) providing the precompiled code that is statically linked (lib files). In both the cases, the code from some third party vendor or the module is included in the software code. These approaches have the two major inherent problems. (a) If the third party updates his module (may be bug fix or new release) we need to re-compile/re-link our code and re-distribute it and (b) if third party module is used in different software application installed on the same machine, the third party code is compiled/linked with multiple software pieces and multiple copies of the same module is present on the system. (Though this is no longer a mentionable problem due to the decrease in cost of storage mediums (memory, fixed and removable media etc)

To target these problems, the idea of dynamically linkable libraries (DLL) emerged that become very popular especially in Windows (may be due to its wide user base). The idea is that a skeleton of the third party module is statically linked with our software. This skeleton executes the third party code that’s present in an external file that’s located and loaded in the runtime. Operating systems may also provide these dynamic linking/loading services. These DLLs can be compiled and linked independent of our software, and if we need to replace some library, all we need is just to replace the DLL file with the new one, there is no need that we re-compile/re-link our software and distribute it. The DLLs can be placed in some pre-selected storage location, so that any software application that needs them can easily locate. (That’s why we have folders with name SYSTEM, SYSTEM32, COMMON FILES in our system) This idea applies to Linux/Unix platforms as well, and people call them Shared Objects on these platforms.

Stay tuned for the next installment, I will be covering the following topics:

·         The role of C++

·         What are Components?

·         Component Object Model (COM)

Published Wednesday, June 30, 2004 10:51 PM by khurram
Filed under:


# re: Introduction to Components: Background

Thursday, July 1, 2004 10:14 AM by Mohammad Furq
Nice Article.
New Comments to this post are disabled