Composite Design Pattern

The Composite Design Pattern is a structural design pattern that allows you to compose objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly.

🔶 Motivation

Imagine you are designing a file system:

• A file is a leaf node (cannot contain other items).
• A directory can contain files and other directories (composite node).

You want to be able to perform operations like getSize() on both files and directories, and treat them the same way in your code. This is where the Composite Pattern is helpful.

🔧 Structure

Participants:

1. Component (interface or abstract class):
2. Leaf (individual object):
3. Composite (composite object):

UML Diagram:

🧾 Example in Java-like Pseudocode

Usage:

✅ Advantages

• Simplifies client code: Treats individual objects and compositions uniformly.
• Makes it easy to add new types of components.
• Supports recursive structures naturally.

❌ Disadvantages

• Can make the design overly general (leaves and composites share the same interface even when it doesn't always make sense).
• May lead to misuse (e.g., a leaf might implement meaningless add()/remove() methods if not handled carefully).

📌 Real-World Use Cases

• GUI Frameworks (Swing, JavaFX, Windows Forms): Widgets can contain other widgets.
• File Systems: Folders (composite) and files (leaf).
• Graphics Editors: Groups of shapes and individual shapes.
• Document Editors: Text, tables, images as composite document elements.

🧠 Best Practices

• Use when your object structure can be represented as a tree.
• Don’t force a uniform interface if not all components need all methods. Consider using exceptions or separating leaf/composite responsibilities.

✅ Use the Composite Pattern when:

1. You have a part-whole hierarchy

• You want to represent objects that can be composed of other objects (e.g., folders containing files or subfolders).
• Example: A directory can contain other directories and files.

2. You want to treat individual and composite objects uniformly

• Clients should be able to treat leaf and composite nodes the same way.
• This simplifies code because you don't have to write special logic for groups vs. single items.

✅ "A File and a Folder both support getSize(), so the client can just call getSize() on any FileSystemItem without knowing what it really is."

3. You need to perform operations recursively over a tree structure

• Operations like render(), draw(), calculateTotalPrice(), etc. can be delegated to children recursively.
• Composite pattern is perfect for recursive tree-like data models.

4. You want to simplify client code

• Clients don’t need to check if an object is a leaf or a composite—they just call the method.
• It reduces the need for complex conditionals like if (object is Folder) then ....

❌ Avoid Composite Pattern when:

✘ The tree structure is not needed.

• If your problem doesn’t involve nesting/grouping, the pattern is overkill.

✘ You need different interfaces for leaf and composite.

• If leaf nodes and composites behave too differently, forcing a shared interface may introduce complexity or confusion.