1. COMPOSITE PATTERN NOTES

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

3. Applicability l Use the Composite pattern when You want to represent whole-part hierarchies of objects You want clients to be able to ignore the differences between compositions of objects and individual objects

4. Structure

5. Participants Component (Component in Java ’ s AWT) Declares the interface for objects in the composition Implements any default behaviour suitable for both Leaf and Composite subclasses Declares an interface for accessing and managing its child components Leaf (TextField, Button, Label etc.) Represents leaf objects in the composition. A Leaf has no children Implements the behaviour for primitive objects in the composition Composite (Container) Implements behaviour for components having children Stores child components Client Manipulates objects in the composition using the Component interface

6. Collaborations l Clients use the Component class interface to interact with objects in the composite structure If the recipient is a Leaf, then the request is handled directly If the recipient is a Composite, then it typically forwards the request to its children

7. Task: apply the Composite pattern l Apply the Composite pattern to model a simple computer file store l A file store is organised into directories and files A file is a primitive object that doesn’t contain other files or directories. All files have a name A directory is a special kind of file which other files may be added to and removed from For any given file, it should be possible to query it for its size For any given directory, it should be possible to query it for the number of children it contains

8. Task l What is the Component class? l What is the Composite class? l What are the Leaf classes? l What are the key Leaf operations? l What are the key Composite operations? l What are the key operations common to Leaf and Composite instances? l What operations should Component declare? Why? l What operations should Component implement? l Draw a class diagram

9. Consequences l The Composite pattern Enables recursive structures to be implemented Where a client expects a primitive, it can also take a composite Simplifies clients since they work with the Component interface Client code does not need conditional statements to check the type of object it is working with Makes it easier to add new components New subclasses of Composite or Leaf can be added without needing to change existing code Can make the design overly general The disadvantage of making it easy to to add new components is that it makes it harder to restrict the components of a composite Run-time checking may be necessary

10. Implementation l There are a couple of key issues to consider when implementing the Composite pattern Explicit parent references Maintaining references from child components to their parents is often desirable  E.g. File objects might need to know their parent so that they could return their full path name It’s essential to maintain the invariant that all children of a composite have as their parent the composite that in turn has them as children  To ensure this, only change a child’s parent when the child is added to or removed from a composite  E.g. File.add(), File.remove()

11. Implementation Declaring child management operations One of the goals of the Composite pattern is to make clients unaware of the specific Leaf or Composite classes they’re using This would suggest that class Component should define as many common operations for Leaf and Composite as possible  E.g. the AWT’s Component class defines all common component operations But, Leaf objects don’t have children! Two solutions …

12. Implementation Solution 1 - define the child management operations in class Component  Promotes transparency – clients treat all components uniformly  Compromises safety – a client might try to add a Component to a Leaf Solution 2 – define the child management operations in class Composite  Safe – an attempt to add a component to a Leaf will be caught at compile time  Loss of transparency – Leaves and Composites have different interfaces The designers Sun chose solution 2 for AWT components  Class Container provides child management operations (e.g. add, remove)

13. Implementation File[] files; for( int i = 0; i < files.length; i++ ) { try { System.out.println( files[ i ].getNumberOfChildren() ); } catch( CompositeException e ) { /* Attempt made to call a composite operation on a leaf file. */ } File[] files; for( int i = 0; i < files.length; i++ ) { if( files[ i ] instanceof Directory ) { System.out.println( files[ i ].getNumberOfChildren() ); } Solution 1 for the File Store problem. Component (File) declares the child management operations and the default behaviour is to throw an exception. Class Directory overrides the child management operations. Solution 2. Directory declares and implements the child management operations. Client code has to check the type of each File object.

14. Implementation Child ordering In many cases, the ordering of children within a Composite is important.  E.g. an AWT layout manager displays a container’ components in the order they were added to the container  Child management operations should be implemented with this ordering in mind Caching Composite can cache traversal information about its children  E.g. with the AWT example, Container could cache the bounding box of its children. In response to a paint request, a Container first checks whether its children are visible in the current window Changes to children may invalidate the cache however  Children should maintain a reference to their parent so that they can inform the parent of the invalided cache

15. Learning outcomes for unit 2 l Can you: Explain the objectives of software design? Analyse designs in terms of reuse and flexibility? Explain the notion of design patterns? Put into practice the Singleton and Composite patterns?