Composite Pattern Himanshu Gupta Shashank Hegde CSE776 – Design Patterns Fall 2011 Good composition is like a suspension bridge - each line adds strength and takes none away. Robert Henri Robert Henri

Intent A Structural Pattern: Concerned with how classes and objects are combined to create larger structures Compose Objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly.

Motivation Can make complex diagrams out of simple components. Easy to deal with tree structured data.

Structure

Participants The classes and objects participating in this pattern are: ◦ Component ◦ Leaf ◦ Composite ◦ Client

Collaborations Client use Component class to interact with objects in composite structure. If recipient is a leaf, then request is handled directly. If the recipient is a composite then it usually forwards request to child component. It may perform additional activities before and after forwarding.

Applicability Can represent part-whole hierarchies of Objects. Supports client ignorance of the difference between composition of objects and individual objects.

Consequences Class hierarchies consists of primitive and composite objects. Clients should treat the composite and leaf uniformly. Makes it easier to add new kind of composite or leaf subclasses. Disadvantage of making design overly general. Harder to restrict the components of a composite.

Implementation Reference from child components to their parents can simplify the traversal and management of a composite structure. Useful to share component. Problem when component can have no more than 1 parent. Composite pattern goal-to make client unaware whether its leaf or composite. As many common operations for composite and leaf. Should components implement a list of Components. Caching to improve performance Who should delete components. –Composite ? Best Data structure for storing components ??

Safety Vs Transparency Usually Composite defines add and remove operation for managing children – what if components does..? Defining child management interface at the root of class hierarchy gives you transparency.It costs you safety. Defining child management interface in composite gives you safety. You lose out on transparency. Solution…??

Sample Code-component #include class component { public: component(void); virtual bool Add(component* addent); virtual bool Remove(component* removed); virtual component* GetChild(int); virtual void operation(); ~component(void); };

Sample Code-Composition #ifndef COMPOSITE_H #include "component.h" #include class Composite :public component { public: Composite(void); ~Composite(void); virtual bool Add(component*); virtual bool Remove(component*); component* GetChild(int); virtual void operation(); private: std::vector children; }; #endif

Sample Code- Leaf #ifndef LEAF_H #include "component.h" #include using namespace std; class Leaf :public component { public: Leaf(void); ~Leaf(void); void virtual operation(); }; #endif

Uses Google Maps PaintBrush. Our example and its extensibility.

Questions???