Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal
"The Whole-Part design pattern helps with the aggregation of components that together form a semantic unit. An aggregate component, the Whole, encapsulates its constituent components, the Parts, organizes their collaboration, and provides a common interface to its functionality. Direct access to the Parts is not possible." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996)
The idea of the Whole-Part pattern is to introduce a component that encapsulates smaller objects, and prevents clients from accessing these constituent parts directly. Define an interface for the aggregate that is the only means of access to the functionality of the encapsulated objects, allowing the aggregate to appear as a semantic unit. The general principle of the Whole-Part pattern is applicable to the organization of three types of relationship: (1) an assembly-parts relationship, which differentiates between a product and its parts or subassemblies (i.e. relationship of a molecule to its atoms). All parts are tightly integrated according to the internal structure of the assembly. The amount and type of subassemblies is predefined and does not go away; (2) a container-contents relationship, in which the aggregated object represents a container. These contents are less tightly coupled than the parts in the assembly-parts relationship. The contents may be dynamically added or removed; (3) The collection-members relationship, which helps to group similar objects--such as an organization and its members. There is no distinction between individual members of a collection--all of them are treated equally. For a more detailed Motivation description for this pattern see: Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996.
This pattern has been used on the following systems: Key abstractions of many object-oriented applications follow this pattern (i.e. some graphical editors support the combination of different types of data to form multimedia documents). They are often implemented according to the Composite design pattern. (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.) Most object-oriented class libraries provide collection classes such as lists, sets, and maps. These classes implement the Collection-Member and Container-Contents variants. (Siemens Nixdorf Informationssysteme AG, Generic++ 2.0, Portable C++ Foundation Class Library, User manual, October 1994.) (Lea, D., Collections, a Java package, http://g.oswego.edu/dl/, 1996.) Graphical user interface toolkits such as Fresco or ET++ use the Composite variant of the Whole-Part pattern. (Gamma, E.,Objektorientierte Software-Entwicklung am Beispiel von ET++, Klassenbibliothek, Werkzeuge, Design, Dissertation, Universitat Zurich, 1991.)
Composite and Façade patterns
Composite pattern, Facade pattern, Whole-Part pattern, Buschmann patterns, design patterns, structural decomposition
any system with large number of whole-part object relationships
need to create complex, aggregate objectsneed to protect clients from knowing if an object is a whole or a part
changeability and extensibility of componentsenhanced maintainability and extensibility of the systempromotes layering of systemsreusabilitysimplifies adding new parts in whole-part relationshipssimplifies the client - permitting the client to treat whole or part objects genericallysupport for many kinds of change
complexity of design and implementationincreased number of objectsrestricted efficiency
Simple implmentation of the pattern - Whole. Whole.javaSimple implmentation of the pattern - Part. Part.javaSimple implmentation of the pattern. wholepart.h