Structural Design Patterns: Composite and Decorator

STRUCTURAL DESIGN PATTERNS

• This presentation discusses structural design patterns, specifically the Composite and Decorator patterns.
• These patterns are used in software design to arrange objects in tree structures or to add functionality in a flexible manner.

COMPOSITE PATTERN

• Also known as Object Tree
• A structural design pattern that allows composing objects into tree structures.
• Enables working with these structures as single or individual objects.
• "Composite" refers to combining or making from different parts.
• Provides solutions for operating on groups of objects and individual objects in a similar way.

REAL LIFE EXAMPLES - COMPOSITE

• File-directory structure is a common real-life example.
• Nodes in this structure can be directories or files.
• Objects may be different types, but treated similarly (e.g., checking size of a file or directory).
• The directory size is the sum of the sizes of all files inside it.
• Employee hierarchy in an organization is another example.
• CEO, managers, and employees are all instances of a person.

COMPOSITE DESIGN PATTERN STRUCTURE

• The pattern has two types of objects: Composite and Leaf.
• Composite Object: Contains other objects; has children (e.g., directory, file folder).
• Leaf Object: A single object; has no children (e.g., file).

WHERE CAN WE USE COMPOSITE PATTERN?

• When representing a part-whole relationship in a tree structure.
• When composite and individual objects are treated uniformly.
• When a parent-child relationship is needed.

STEPS TO IMPLEMENT COMPOSITE DESIGN PATTERN

• Define leaf and composite objects as the same data type.
• Implement common methods in leaf and composite objects.
• Leaf nodes perform their own desired behavior.
• Composite objects write customized functions for each child to call.

STRUCTURE & PARTICIPANTS

• Component: Declares interface for objects in composition and implements default behavior.
• Leaf: Represents leaf objects in composition; has no children; defines primitive object behavior.
• Composite: Defines behavior for components with children; stores child components; implements child-related operations.
• Client: Manipulates objects in composition through the Component interface.

UML DIAGRAM FOR COMPOSITE DESIGN PATTERN IMPLEMENTATION

• The diagram shows how to implement the pattern with interfaces for "File" and classes for different file types (e.g., "Directory," "TextFile").

IMPLEMENTING COMPOSITE DESIGN PATTERN IN JAVA

• Develops an example for file directory structure with root, subdirectories and files.
• Shows example Java code for a file interface and classes for TextFile and Directory with implemented methods for type and size.

APPLICATION CLASS (JAVA CODE)

• Shows how to create and interact with composite objects in Java.
• Includes the use of getSize() methods on composite and leaf objects.

PROS AND CONS - COMPOSITE

• Pros: Data representation as a tree structure, uniform operations, reduced overhead, and open/closed principle support.
• Cons: Objects should be compatible, complexity can be increased.

DECORATOR PATTERN

• A structural design pattern that adds new behaviors to objects by placing the objects inside special wrapper objects.
• The decorator uses composition, not inheritance, to extend the behavior of an object at runtime.
• Also known as wrapper pattern.

WHERE TO USE THE DECORATOR PATTERN

• When objects are extended dynamically without altering the original code.
• When extending behavior is not straightforward using inheritance, due to existing final classes.

UML CLASS DIAGRAM & PARTICIPANTS (DECORATOR)

• Component: Defines the interface for objects to have responsibilities added dynamically.
• Decorator: Implements the same interface as the component being decorated; has a HAS-A relationship with the decorated object.
• ConcreteComponent: The object that will be dynamically enhanced.
• ConcreteDecorator: Decorators that enhance the component (add new methods).

COFFEE SHOP EXAMPLE

• Shows a situation where using inheritance to add new features (condiments, etc.) results in a huge number of classes.
• Demonstrates a potential solution using the decorator pattern.

APPROACHES TO SOLVING THE COFFEE SHOP PROBLEM

• Approach 1: Uses boolean variables in the Beverage class to indicate condiments, but results in difficulty maintaining code when new condiments are introduced.
• Approach 2: The decorator approach (using the decorator pattern) is a more maintainable solution.

DECORATOR PATTERN IMPLEMENTATION

• Shows code for a Beverage abstract class and subclasses, including examples of concrete classes like DarkRoast and Mocha, with override methods to add cost for condiments and descriptions for printing.

PROS AND CONS - DECORATOR

• Pros: Ability to extend object behavior without subclassing, runtime addition/removal of responsibilities, and combined behaviors.
• Cons: Difficulty in removing specific decorators in a large chain, code maintainability issues with multiple similar decorators.

QUESTIONS - REVIEW (SUMMARY)

• Composite: Composing objects into tree structures, enabling use as single units.
• Decorator: Adding behaviors to objects through wrappers, extending object functionality without subclassing.