Group Packaging

Pattern: Group Packaging

Component classes must be "packaged" so that they can be deployed. Packaging supports the integration of components into a system by providing the ability to instantiate components, query their interfaces and bind them to the roles that they must play in the AbstractInteractions used in the system.

                           ***

You are developing multiple component classes for use within a ComponentFramework. They must be packaged for deployment.

Too many component classes in one package can introduce redundant deployment for users who don't need all the classes. Packaging component classes individually increases initialisation time if components are linked into the system at run-time.

The component classes are closely related or are designed to be used together. Users will most probably instantiate the majority of the component classes in the same system.

Therefore: Package multiple component classes in a single unit of deployment when those components are very likely to be used together.

                           ***

Group Packaging closely related components reduces the overhead due to loading unused code, because a system is likely to instantiate most of the component classes in the package. If a system is most likely to use individual component classes, use IndividualPackaging.

Examples of this pattern include:

• Tcl/Tk: all the basic Tk user-interface components (widgets) are bundled together in the Tk package. Specialised widgets, such as those for drawing charts or visualising audio data, are provided as additional packages.
• The Java security framework is packaged as a single JAR file containing basic cryptographic algorithms. Extensions to the security framework that contain other cryptographic algorithms are packaged in additional JAR files and loaded by the basic framework.

This page mirrored in ComponentDesignPatterns as of April 29, 2006