Page #17 (Chapter 1. The Component Model)

< BACK  NEXT >

[oR]

Component Reusability

It s late in the afternoon on Friday. No meetings were scheduled today, so you ve spent most of your time implementing a very creative algorithm that will be incorporated in the forthcoming release of the product. Everything is coming together very well and the project is on schedule for delivery this is too good to be true. You earned your pay and then some, especially considering your brutal effort over the past month. This weekend is going to be a welcome relief. As you sit back with a blank stare at the screen, lost in thoughts about your plans for the weekend, the project manager walks into your office and asks, Dave, can we add support for browsing a web page within our application? You take a deep breath and look at the ceiling as you focus on the problem and start thinking. We will need to do some low-level socket programming to connect to a web site. We will need to parse the HTML document and display user interface components such as buttons, edit boxes, etc. As if this is not enough, we will also need to deal with embedded scripts in the HTML document. How about dealing with firewalls and proxy servers? To top it off, keeping up with browsing technology is not easy. From HTML to DHTML to XML and XSL, there is no end to it. So you reply, This is a lot of work and certainly not something we will be good at. Given the amount of resources and the deadlines we have, I think we will be better off not implementing this feature. Your manager considers this to be an unsatisfactory solution and is disappointed with your response. You are exhausted and feel guilty about having to upset your manager, but then what choices do you have? After all, you are aware of the consequences of feature creep. Are there any alternatives?

You sit back at your desk and start thinking. Companies such as Netscape (now owned by AOL) and Microsoft have already developed the technology for browsing the web. And they continue to maintain and upgrade it. Why can t I leverage their work in a way that is transparent to the user? Why can t we all live together happily?

This very thought is what COM is built on (well, except for the last part, which requires a force more powerful than COM). The ability to reuse one or more software components so that all the components integrate seamlessly and don t break when any individual component is upgraded is where the component model began.

Reusability of components is not a new concept. Hardware equipment has supported this notion for a long time. For example, I recently put together a home entertainment system. I bought a Sony amplifier/receiver, a GE TV, Energy speakers, a Pioneer DVD player, and a JVC DSS receiver. I hooked various inputs and outputs of all these components together and turned the system on. Voila! My TV was showing a channel received through the DSS receiver and the speakers were playing sound using Dolby surround sound technology. Through the supplied remote, I could conveniently switch between the satellite channel and the DVD player.

My home system operates as a single unit despite various hardware components from different manufacturers, each of which had little idea what the other components really did or what kind of internal circuitry the other components used. How was this possible? Was this magic?

Magic or not, it worked for hardware. Could we make it work for software?

< BACK  NEXT >