The Composite Pattern allows you to compose objects into tree structures and treat the individual object and composite objects uniformly.
The Composite Pattern is similar to the Decorator Pattern I presented in my last post. Both patterns are of structural nature. The main difference is that the Composite Pattern composites tree structures, but the Decorator Pattern only has one object.
Here are more details about the Composite Pattern.
- Combines objects into tree structures to handle them uniformly
- Represents part/whole hierarchies
- Clients can treat single and composite objects equally
- Defines the interface
- Defines an interface so that the
Composite(parent) can access its
Component‘s child (optionally)
- Represents the singular object
- Implements the interface
- Represents the composite object
- Defines member functions to manipulate its children
When you perform an operation on the tree structure, the operation can be performed on a leaf node or a composite node. The operation is directly performed if it is a leaf node. The operation is delegated to all children components if it is a composite node. A composite node has a list of children and member functions to add or remove those. Consequentially, each component (leaf node or composite node) can handle the operation appropriately.
In this example
Graphic defines the interface for all concrete components.
GraphicComposite stands for the composite node and
Ellipse stands for the leaf node.
GraphicComposite holds its children in a
std::vector<const Graphic*> (line 1), and supports operations to add and remove children (lines 2 and 3).
Each component has to implement the pure virtual function
Ellipse displays it
name (line 4). The
GraphicComposite also displays its
name but, additionally, delegates the show call to its children (line 5).
The main program creates a tree structure with the root
graphic. First, the tree
graphic is displayed with the subtree
graphic1 (line 6) and then without it (line 7).
Applying an algorithm such as find or find_if on a container of the Standard Template Library can be regarded as a simplified application of the Composite Pattern. This is particularly true if the container is an ordered associative container like std::map.
- The Decorator Pattern is structurally similar to the composite. The main difference is that the Decorator Pattern has only one child. Additionally, the Decorator Pattern adds new responsibility to an object, while the Composite Pattern sums up the results of its children.
- The Iterator Pattern is typically used to traverse the components of the tree.
- The Visitor Pattern encapsulates operations in objects applied to the components of the tree.
Pros and Cons
Let me start with the benefits.
- Thanks to polymorphism and recursion, you can treat complex tree structures uniformly
- It is pretty easy to extend the tree structure with new components
- Each new operation on the component must be implemented on the leaf node and the composite node
- The delegation of operations adds additional run-time costs
With the Facade Pattern, the book “Design Patterns: Elements of Reusable Object-Oriented Software” provides an additional structural pattern. The intention of the Facade Pattern is to provide a simplified interface to a complex library or framework.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, and Philipp Lenk.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
|My special thanks to SHAVEDYAKS|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,