- Objects, Components, and COM
- Abstraction and Class Modeling
- Association Relationships
- One-to-One Relationships
- One-To-Many Relationships
- Class and Object Naming Conventions
- Component-Based Development
- Component-Based Development and COM
- COM-Definable Entities
- Component Coupling
With some object-orientation fundamentals behind us, we turn our discussion to component-based development (CBD). Many people feel that objects and components are synonymous, when in fact, they are more like siblings. Objects can exist without components, and vice-versa. A component is a reusable, self-contained body of functionality that we can use across a broad application base. Imagine an application suite that has a core piece of functionality contained in an includable source code module. Making a change to this functionality requires that we modify and recompile the source code, testing all applications that are using it. We must then distribute every application that references it. In large applications, this compile time can be extensive. In a component-based model, we can simply modify the component and do the same recompile, test, and distribute just on that component without affecting the applications.
As we alluded in our discussion on layers and tiers in Chapter 2, "Layers and Tiers," a CBD approach has some distinct advantages during the development process. Chief among these is the ability to develop and test components in isolation before integrated testing.