Structural Design Patterns: Composite Pattern

STRUCTURAL DESIGN PATTERNS

• Structural design patterns compose classes or objects into larger structures, and then define ways to use these structures

COMPOSITE PATTERN

• Also known as: Object Tree
• Composite is a structural design pattern that lets you compose objects into tree structures and then work with these structures as if they were individual objects
• From the name, "Composite" means the combination or made from different parts
• This pattern provides a solution to operate on groups of objects and single objects in a similar way
• Real-life examples include file-directory structures, where a node can be a directory or a file
  • Even though directories and files are different types of objects, they can be treated similarly (e.g., checking the size of a directory, which is the sum of sizes of all files within that directory)
• Another real-life example is employee hierarchy structure (CEO, managers, employees)
  • All employees, managers and the CEO are instances of a person
•  Structure of the composite pattern:
  • 1. Composite Object: An object that contains other objects. This can be a directory (file folder)
  • 2. Leaf Object: A single object that does not have children (e.g., a file).

WHERE CAN WE USE COMPOSITE PATTERN?

• When you want to represent a part-whole relationship in a tree structure (Objects can be represented in a tree structure hierarchy)
• Composite and individual objects are treated uniformly
• Need to define parent-child relationships

STEPS TO IMPLEMENT COMPOSITE DESIGN PATTERN

• Define leaf and composite objects as the same data type
• Implement an interface or extend a class
• Write common methods for all leaf and composite objects
• Leaf node performs its own desired behavior
• Composite object writes a customized function or each child of this node can call this function

STRUCTURE & PARTICIPANTS

• Component: Declares an interface for objects in the composition, and implements default behaviors common to all.
• Leaf: Represents leaf objects in the composition; doesn't have children; defines behavior for primitive objects.
• Composite: Defines behaviors 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.

UML DIAGRAM FOR COMPOSITE DESIGN PATTERN IMPLEMENTATION

• Shown in the image will create an interface for " File ".
• Will have two different classes one for directory type and second for classes other than directory (.txt, .doc, etc).

IMPLEMENTING COMPOSITE DESIGN PATTERN IN JAVA

• Example for file directory structure
• Create child file and root directories.
• Get size of files and directories

COMPOSITE DESIGN PATTERN CLASS IMPLEMENTATION(JAVA)

• Classes for file and directory types (e.g., TextFile, Directory)
• Directory implements File and stores a list of File objects
• TextFile implements File and has size

APPLICATION CLASS (JAVA)

• Implements main method for testing the code
• Create TextFile objects child1 and child2
• Create Directory object root
• Add child1 and child2 to root
• Print sizes of child1 and root.

PROS AND CONS OF COMPOSITE PATTERN

• Pros:
  • Data represented as a tree structure
  • Same operations on different object types
  • Reduces overhead for handling different types of objects
  • Open/Closed Principle: introducing new elements without breaking existing code
• Cons:
  • Objects must be compatible
  • Complexity can increase

DECORATOR PATTERN

• Decorator is a structural design pattern that lets you attach new behaviors to objects by placing them inside special wrapper objects that contain the behaviors
• Uses composition instead of inheritance to extend an object's functionality at runtime.
• Also known as Wrapper
• Wrap a component with any number of decorators (e.g., wrapping a gift, putting it in a box, wrapping the box).
• Change component behavior by adding new functionality before and/or after method calls to the component
• Provides an alternative to subclassing for expanding behavior

WHERE CAN DECORATOR PATTERN BE USED?

• Attach additional responsibilities to objects at runtime without altering code using these objects
• Use when it's hard to extend object behavior with inheritance
• Programming languages with the final keyword used to prevent further extension of a class

UML CLASS DIAGRAM & PARTICIPANTS

• Component: Defines an interface for objects that can have responsibilities added dynamically
• Decorator: Decorators implement the same interface as the component; have a relationship with the object they extend (a has-a relationship).
• ConcreteComponent: Object to be enhanced dynamically. Inherits from Component.
• ConcreteDecorator: Decorators that enhance the state of the component, can add new methods, adding new behavior before or after existing methods.

COFFEE SHOP EXAMPLE

• Introduces a coffee shop, serving four beverage types (house blend, dark roast, decaf, espresso).
• Starts by using inheritance but quickly realizes this leads to many classes for various combinations of beverages and condiments.
• Example of "class explosion" caused by overuse of inheritance.
• Suggests alternative approach to handle condiments.

APPROACH 1

• Add boolean variables in Beverage class to represent condiments (milk, soy, mocha, whip)
• Override the cost method in specific concrete Beverage classes

APPROACH 2

• Use Decorator pattern to dynamically add condiments
• Components are Beverage classes (DarkRoast, etc.)
• Decorators are classes that add behavior to the Beverage object (e.g., Whip, Mocha)

UML DIAGRAM OF DECORATOR PATTERN (EXAMPLE: MOCA AND WHIP DECORATIONS)

• Graphic shows a DarkRoast class.
• Shows how Mocha and Whip components add new behaviors, building up functionality

DECORATOR PATTERN CLASS DEFINITION (EXAMPLE: MOCA CLASS)

• Implments Beverage class
• Has a beverage that it wraps

IMPORTANT NOTE ON DECORATOR PATTERN

• Decorator is a subclass of the Component class
• You cannot create a ConcreteDecorator without a ConcreteComponent

PROS AND CONS OF DECORATOR PATTERN

• Pros:
  • Easily extend objects' behavior without creating subclasses.
  • Add and remove behaviors at runtime
  • Combine multiple behaviors using decorators.
• Cons:
  • Hard to remove a specific decorator from the stack.
  • Code maintainability can be challenging as decorators can get numerous and similar; difficult to maintain and distinguish

QUESTIONS

• Composite: Composing Objects into Tree Structures
• Decorator: Adding Behaviors to Objects by Placing them Inside Wrappers