- Objects, Components, and COM
- Abstraction and Class Modeling
- Encapsulation
- Polymorphism
- Inheritance
- 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
- Summary
Component Coupling
With the flexibility to place COM classes into components and then have these components reference each other, it can become easy to create an environment of high coupling. Coupling occurs when we create a reference from a COM class in one component to the interface of a COM class in another component. Because components are different physical entities, this has the effect of hooking the two components together relative to distribution. Wherever we distribute a component that references other components, we also must distribute all the referenced components, all their referenced components, and so on. One reason for coupling is that we might not properly group functionality into common components. Functionality that represents a single subpart of the overall business application might be a good candidate for a single component. Alternatively, functionality that represents similar design patterns might belong in a single component.
TIP
It is important during the analysis and design phases to group components based on similar functionality. Although we invariably need to create system-level classes for use by other classes, we should try to minimize the creation of a chain of component references. These chains lead to administration and maintenance issues after the application is in production.
Another issue that leads to coupling is that we try to over-modularize the application by placing small snippets of subparts into components. Beyond the coupling aspects, each ActiveX DLL has a certain amount of overhead to load and retain in memory. Placing functionality in ten components when two would suffice adds unnecessary performance overhead and complexity to your application.
From a performance perspective, we can look at the time necessary to initialize the two scenarios. There are two initialization times to look at: the first is the time required to initialize the component, and the second is the time required to initialize the object. Remembering that a component in the COM world is a specialized DLL, we can infer that some initialization time is associated with the DLL. When Visual Basic must load an ActiveX DLL, it must go through a process of "learning" what objects are defined in the component in terms of properties, methods, and events. In the two scenarios, the 10-DLL case will have five times the load time of the 2-DLL case, assuming negligible differences in the aggregate learning time of the objects within the components.
From a complexity perspective, the more components created means more work on the development team. One of the problematic issues with any object-oriented or interface implementation project is that of recompilation and distribution when something changes, especially in the early development phases of the application. For example, if the definition of a core class referenced throughout the project changes, it is much easier to recompile the two components versus the ten. As you might already know from multitiered development in the DCOM environment, propagating such seemingly simple changes across tiers can be very difficult. Thus, appropriate minimization of the number of components up front is desirable.
We are not trying to say that you should place all your functionality into one component—this leads to its own set of problems. The moral of the story is that one should not force modularity purely for the sake of doing so. You should find an appropriate balance that can come only from experience in developing these sorts of systems. The framework presented in Part II is a good starting point for understanding where these lines of balance should be drawn.
When we need to provide a superset of functionality based on classes in separate components, there is a tendency to have one class directly reference the other to do this. In this case, we can put the new functionality on an existing class or we can implement a new class within one of the components to handle this. Remember that the tenant of CBD is ultimately a high level of modularity. If we design our components well, there might be other applications that need the base functionality afforded by one component, but not that of the secondary component or the bridging functionality binding them together. If we design our components in the manner just discussed, we must distribute both components just to get to the little bit of functionality that we need in one.
TIP
To minimize coupling between loosely related components, it is always better to build a third component to provide the bridge between the two components. In this manner, each can be distributed independent of the other.
Figure 3.11 shows tight coupling, whereas Figure 3.12 shows its bridged counterpart.
){kind=link}
){kind=link}
Figure 3.11 A graphical representation of tight coupling.
In Figure 3.11, it should be clear that components A and B must travel together wherever they go. An application that only needs component A must bring along component B as well. An application that uses component A might go through test, debug, and redistribution whenever component B changes, although it is not using it.
In Figure 3.12, we show components A and B bridged together by component C. In this implementation, both A and B can be used singularly in applications, whereas applications that need the bridged functionality can use component C to provide this.
Figure 3.12 A graphical representation of bridged coupling.