If you've followed the software industry for long then you'll have realized that object-oriented technology is not exactly new any more. In fact, it's been around for many years; but only now is it really becoming a popular concept in business. Why is that?
There are probably a lot of different reasons, but there is one in particular that we need to explore. As we discussed earlier in the chapter, a lot of the impetus for new development techniques is to facilitate code reuse. Unfortunately, just creating objects in code is not enough to maximize reuse.
Until recently, if we had the code for a Customer object in one program, and we wanted to use that object in another application, we'd have to copy the code into our application. We got to reuse the code, but, if anything changed, we had to find and change each copy of the customer object in all the different applications where it could be in use.
The problem is that as soon as there are two or more different copies of the same code, there's no easy way to keep them all synchronized. In many ways, we're back where we started - with simple copy-paste code reuse. At best, we've simply come up with a new way to create source code libraries:
This is where component-oriented design comes in. Components build on object technologies to provide a better way of achieving reuse of our objects.
The term component is one of those overloaded words that has a different meaning to just about anyone you'd care to ask. Even within the OO community, there's a great deal of disagreement about the meaning of the term. Many people would argue that a component is nothing more than a large or complex business object.
In fact, the terms 'object' and 'component' are often used interchangeably, but there's a distinct and important difference between them:
Since we're using a Microsoft development tool to create software for Microsoft operating systems, we'll stick with Microsoft's definition of a component. In their view, components are ActiveX servers or ActiveX controls. They are precompiled units of code that expose one or more interfaces for use by client programs:
Even within the Microsoft world you'll find some confusion. To many people, ActiveX controls and components are synonymous. In reality, however, ActiveX controls are merely one type of component, along with various other types of ActiveX servers. We'll look at all these different types of components in the next section.
With binary components, we can achieve a whole new level of reuse in our applications. Going back to our Customer object, we can put the code into our component rather than into each individual application. The applications can then use the object directly from the component:
We get the same functionality as when we copied the source code into each application, but now we only need to maintain that code in a single place - the component.