Rogue Wave banner
Previous fileTop of DocumentContentsIndex pageNext file
Stingray Foundation Library User's Guide
Rogue Wave web site:  Home Page  |  Main Documentation Page

4.3 The Composite Pattern

The composite pattern composes objects into tree structures to represent part-whole hierarchies. The composite pattern lets client code treat individual objects and compositions of objects uniformly. For example, a composite shape is made up of several individual shapes such as rectangles and ellipses. The composite pattern allows simple shapes and complex shapes to be handled the same way.

The CComposite template class provides an implementation of the composite pattern. It maintains a list of child objects that are accessed through methods such as AddChild(), RemoveChild(), and GetChildrenCount(). In addition to having a list of children, each composite object maintains a pointer to its parent. The declaration of this templated class is shown in Example 10

Example 10: CComposite class declaration

The first parameter passed into the CComposite template is the component type, which determines the type of parent and child objects in the composite. Objects in the tree are accessed using that type. For example, the declaration of the GetParent() method returns a pointer to a _Component object, not a CComposite<> object:

The second parameter in the template is a GUID that will identify the composite interface within the set of interfaces implemented by the component classes. The composite implementation does not assume an inheritance relationship between the CComposite<> class and the _Component class. Rather than an implicit conversion, casting from one to the other is performed using the guid_cast<> mechanism, standard in SFL. Whenever the CComposite<> interface is needed in some operation, a guid_cast<> is performed using the GUID passed in the second template parameter. Derived classes are responsible of providing an adequate interface map that allows this guid_cast<> call to succeed. All classes that mix in the CComposite<> template among their base classes are indirectly deriving from IQueryGuid, as seen earlier in Example 10.

Example 11 uses the CComposite class to compose complex shapes from simple shapes. The sample defines an entire class hierarchy that mixes in the composite pattern for all of its classes.

Example 11: Composing complex shapes

Example 12 sets up a composite tree with three descendents, one of which is, in turn, a composite.

Example 12: Setting up a composite tree


CComposite<> does not make any assumptions about the allocation of the children, and therefore does not deallocate them upon destruction of the object.

That means that in Example 12, the objects that were allocated using the new() operator should be deallocated by some external agent before the root of the composite gets destroyed. Otherwise, a memory leak will occur.



Previous fileTop of DocumentContentsNo linkNext file

Copyright © Rogue Wave Software, Inc. All Rights Reserved.

The Rogue Wave name and logo, and Stingray, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.