1. The Composite Pattern.

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

3. 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.

4. 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.

5. Composite Pattern

7. 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

8. Composite pattern Structure:

9. Composite Pattern Composite Object structure

10. 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

11. 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.

12. 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.

13. 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

14. Composite Pattern

15. 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.

16. 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.

17. 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:

18. 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(); }... }

19. 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:

20. Example1

23. Example2

25. Example3- The Java AWT