Page #18 (Component Reusability)

< BACK  NEXT >

[oR]

Traditional Software Reusability

The original problem of adding web-browsing functionality to an application can be addressed in the following two ways:

• Obtain the complete source code for web-browsing from a third-party software vendor, compile and link the source code, and create the application executable. This technique, however, is not that prevalent, as most software vendors do not wish to share their source code.

• Obtain precompiled code in the form of a statically linkable library. The vendor supplies two pieces of information, a C++ header file (WebBrowser.h, for example) that contains the web-browsing class definition, and a static link library (WebBrowser.lib). You include the header file in your application s source code, compile the source code, then link the code with the static library to create the application s executable.

In either case, the programming logic from the software vendor has been absorbed. The header files and the library files are no longer needed to run the application.

There are several problems associated with such traditional approaches to software reusability, including the following:

• Let s say the software vendor found a defect in its implementation after you have shipped your application. The vendor is very cooperative and provides you with an updated library and the corresponding C++ header file. However, there is no way for you to field-replace the web-browser implementation by itself. You are forced to recompile your source code with the new header file, relink your code with the new library, and ship the new application(s) to the user. Ever bought a TV-VCR combo unit? Each time something breaks down in the VCR, you have to take the TV along with it to the repair shop. Do you feel the pain?

• Assume that the web-browser library occupies 50MB worth of space in your application s executable image, and that your software suite consists of four applications, each application linked with this library. Now you end up taking a whopping 200MB of hard disk space on the enduser box for what is essentially the same piece of code. Worse yet, when the user runs all the applications simultaneously, the same piece of code gets loaded into memory four times.

In order to overcome these problems, we need to take a closer look at the roles of the linker and the OS loader. However, before we go further, let me define our sample reference that we will use in this chapter.

< BACK  NEXT >