The Composite Pattern

The Composite Pattern .

Composite Pattern • Intent • Compose objects into tree structures to represent part-whole hierarchies. • Composite lets clients treat individual objects and compositions of objects uniformly.

Composite Pattern • Motivation Graphic applications let users build complex diagrams out of simple components. A simple implementation can define a class for primitives and other classes that act as containers for these. Problem: The code that uses theses classes is forced to treat primitives and container objects differently.

Composite Pattern • Motivation: - Using Composite pattern clients do not need to make this distinction. - Graphic, Line, Text, Picture The key: The abstract class that represent both primitives and their containers.

Composite Pattern

Composite Pattern • Applicability (use the pattern when…) • You want to represent part-whole hierarchies of objects • You want clients to be able to ignore the difference between compositions of objects and individual objects

Composite pattern Structure:

Composite Pattern • Composite Object structure

Composite Pattern • Participants • Component (Graphic) • Declares the interface for objects in the composition • Implements default behavior for the interface common to all classes, as appropriate • Declares an interface for accessing and managing its child components • (Optional) Defines an interface for accessing a component’s parent in the recursive structure, and implements it if that’s appropriate • Leaf (Line, Text, Rectangle) • Represents the leaf objects in the composition. A leaf has no children • Defines behavior for primitive objects in the composition. • Composite (Picture) • Defines behavior for components having children • Stores child components. • Implements child-related operations in the Component interface • Client • Manipulates objects in the composition through the Component interface

Composite Pattern • Collaborations Clients use the Component class interface to interact with all objects in the composite structures. If the recipient is a leaf it is handled directly, If it is a composite, it is passed to its children.

Composite Pattern • Consequences 1- Wherever client code expects a primitive, it can also take a composite object 2- Makes the client simple 3- Makes it easy to add new kinds of components 4- Disadvantage: Sometimes you want a composite to have only certain components, you can not rely on type system to enforce those restrictions.

Composite Pattern • Implementation • Explicit Parent References The usual place to define the parent reference is in the component class. The easiest way is to add and remove the reference when a leaf is added or removed from the composite • Sharing Components • Share components to reduce storage requirements • Becomes difficult when? When a component can only have one parent • Which pattern makes this easier? Flyweight • Maximizing the Component Interface • Component class should define as many common operations for the Composite and Leaf classes as possible How returning children would be implemented for leaf for example? • Declaring the Child Management Operations Trade off between: • Transparency vs Uniformity • Safety Clients may try to do meaningless things like add and remove objects from leaves • It is better let component fail and raise an exception if it is not allowed to add or remove children

Composite Pattern

Composite Pattern • Implementations (cont.) • Should Component Implement a List of Components? • Child Ordering • Sometimes it is useful to provide ordering. To do this just be careful when writing your Add/Remove children methods • Iterator pattern (p257) comes in handy here • Caching to Improve Performance • If caching is needed extra caching information should be stored in the Composite class • Who Should Delete Components? • In a language without Garbage Collection its best to have Composite responsible for deleting its children when it’s destroyed • What’s the Best Data Structure for Storing Components? • Basically any will work (Linked List, trees, arrays, Hash Tables, etc) • The trick to choosing will be (as per usual) the efficiency trade-offs • Sometimes composites have a variable for each child, although this requires each subclass of Composite to implement its own management interface. See Interpreter (p243) for an example.

Composite Pattern • Known Uses Almost all complex systems, MVC, every user interface toolkit or framework • Related Patterns Decorator is often used with composite, Flyweight lets you share components, but they can not refer to their parents Iterator can be used to traverse the composites Visitor localizes operations and behaviors that otherwise be distributed across composite and leaf classes.

Example1 • Situation: A GUI system has window objects which can contain various GUI components (widgets) such as, buttons and text areas. A window can also contain widget container objects which can hold other widgets. • Solution 1: What if we designed all the widgets with different interfaces for "updating" the screen? We would then have to write a Window update() method as follows:

Example1 public class Window { Button[] buttons; Menu[] menus; TextArea[] textAreas; WidgetContainer[] containers; public void update() { if (buttons != null) for (int k = 0; k < buttons.length; k++) buttons[k].draw(); if (menus != null) for (int k = 0; k < menus.length; k++) menus[k].refresh(); // Other widgets handled similarly. if (containers != null) for (int k = 0; k < containers.length; k++ ) containers[k].updateWidgets(); } ... }

Example 1 • Well, that looks particularly bad. If we want to add a new kind of widget, we have to modify the update() method of Window to handle it. • Solution 2: We should always try to program to an interface, right? So, let's make all widgets support the Widget interface, either by being subclasses of a Widget class or implementing a Java Widget interface. Now our update() method becomes:

Example1

Example2

Example3- The Java AWT

The Composite Pattern