Design Concept - Components

System factored into policy, implementation, and utility components

Example Component Structure

• Components are packages that export only two things: 1) an interface, and 2) an object factory. Clients can create instances of all the objects the package needs to implement its services using the object factory. The factory returns a package interface pointer, bound to its internal implementation. The client uses the interface to access package services.
• The interface allows clients to bind to a service abstraction without binding to any implementation detail. The factory supports initialization of the service without binding its clients to that startup process. Hence, clients are completely isolated from the component implementation.
• The first diagram shows a sensible decomposition of a system into a policy part responsible for meeting application requirements, an implementation component that implements the policy using a utility component for low-level operations. In a real system, each of these would probably be implemented with more than one component.
• If this decomposition was implemented with ordinary classes, the result would be concrete bindings that linked all levels of the system. Changes to a low-level utility part could cause breakage all the way to the top policy parts.
• Using the component structure, e.g., exposing only interfaces and object factories, a component at any level can be modified and rebuilt without causing any design or compilation breakage. We simply need to relink the component into the system.

  If we build each of the components as dynamic link libraries (DLLs) loaded by an executive, then we don't even need the link phase. We simply modify and rebuild the component and copy its new DLL into the directory where the executive looks for libraries to load. That replaces the old component with the new one. Since libraries are loaded when the executive starts, the new part begins its service.

Conclusions: