Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (1) –A structural design pattern Decouples interface from implementation –Intent To structure composites into a tree structure; to let clients deal with individual objects and compositions of objects uniformly

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (2) –Problem Situation I: Wish to represent recursive data Situation II: Wish to isolate client from worrying about whether the data is a terminal case or a recursive case

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (3) –Non-software example Arithmetic Expressions –Operations can be applied to terminals and composites alike

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (4) –Abstract Description Object Design Pattern Key relationships

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (5) –Abstract Description Sequence Diagram

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. 1-6 The Composite Design Pattern (6) getMachineCount() returns the number of machines in any given component (Machine returns 1; MachineComposite returns sum of the counts for each component) MachineComponent getMachineCount() components: List getMachineCount() MachineComposite Machine getMachineCount()

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (7) –Consequences Recursive data structures lends itself to recursive processing Simplifies the client –No concern for looping on composites Explicit hierarchy makes it easier to add new leaf of composite types

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (8) –Implementation Issues Typically necessary to have multiple types of composites –Numbers and roles of composite parts Composite should protect its internal data structure –If necessary, give client iterator over component parts Maximize the abstract interface for client isolation –Provide all methods of all derived classes –Isolates client from needing to type cast to get what they need

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (9) –Implementation Issues Where should we declare the “child management” methods? –For example – addChild, removeChild, … –Option I : in the Component class »again, isolates client from distinction »costs safety, meaningless to add to leaf »can add default behavior for all composites –Option II: in the Composite class »Safe – only defined on composites »Creates different interfaces for leaf and composites »Can provide “isComposite” to help with safe type casting

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (10) –Implementation Issues Don’t declare “child list” in Component –tempting if child management introduced at this level –costs space in all leaf nodes Pointers to parents –Makes certain kinds of traversal easier

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (11) –Example: Kaleidoscope Could support Shapes built from other shapes Sample Code public abstract class Shape {... } public class CompositeShape { protected Vector parts; public void addPart(Shape s){…} public void draw(Graphics g){ for(int i=0 ; i<parts.size(); i++){ ((Shape)(parts.get(i))).draw(g); }... Example of when to not use “final”

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. The Composite Design Pattern (12) –Common Variations None –Java API Usage java.awt.Component