I need write permission to create the entry file. Here's the structured summary I've prepared:

GoF Composite and Decorator Structural Patterns

This entry covers two structural patterns from the Gang of Four catalog—Composite and Decorator—that both use recursive composition through a common interface but for different purposes. Composite models part-whole hierarchies so clients treat individual objects and collections uniformly. Decorator wraps objects to add responsibilities dynamically without subclassing.

---

Key Concepts

Composite Pattern

• Intent: Compose objects into tree structures to represent part-whole hierarchies; let clients treat individual objects and compositions uniformly.
• Core abstraction: An abstract Component class that represents both primitives (Leaf) and containers (Composite), declaring operations common to both.
• Recursive composition: A Composite holds a collection of Components, each of which may itself be a Composite, enabling arbitrarily deep nesting.
• Uniform client interface: Clients interact only through the Component interface—they never need to know whether they hold a Leaf or a Composite.
• Transparency vs. safety trade-off: Declaring child-management operations (Add/Remove) in Component gives transparency (uniform interface) but sacrifices safety (meaningless operations on leaves). Declaring them only in Composite gives compile-time safety but requires type-testing.
• Consequences: Simplifies client code by eliminating type-checking conditionals; makes adding new component types easy; but can make designs overly general since you cannot rely on the type system to restrict which components a composite may contain.

Decorator Pattern

• Intent: Attach additional responsibilities to an object dynamically. A flexible alternative to subclassing for extending functionality.
• Also known as: Wrapper.
• Core mechanism: A Decorator holds a reference to a Component, conforms to the same interface, and forwards requests—optionally performing additional work before or after.
• Recursive nesting: Decorators can be nested arbitrarily (e.g., BorderDecorator wrapping ScrollDecorator wrapping TextView), each adding one responsibility.
• Run-time flexibility: Responsibilities can be added and removed at run-time by attaching/detaching decorators, unlike inheritance which is static.
• Consequences: More flexible than static inheritance; avoids feature-laden base classes; but produces many small objects that can be hard to debug, and breaks object identity (a decorated component is not == to the original).

Commands and Syntax

Composite — GetComposite for safe downcasting (C++)

virtual Composite* GetComposite() { return 0; }       // Component default
virtual Composite* GetComposite() { return this; }     // Composite override

if (test = aComponent->GetComposite()) {
    test->Add(new Leaf);  // safe — only executes on actual composites
}

Composite — Equipment hierarchy example

class Equipment {
public:
    virtual Watt Power();
    virtual Currency NetPrice();
    virtual void Add(Equipment*);
    virtual void Remove(Equipment*);
    virtual Iterator<Equipment*>* CreateIterator();
};

// Assembly
Cabinet* cabinet = new Cabinet("PC Cabinet");
Chassis* chassis = new Chassis("PC Chassis");
cabinet->Add(chassis);
chassis->Add(new FloppyDisk("3.5in Floppy"));
cout << chassis->NetPrice() << endl;

Relationships

• Composite <-> Iterator: Iterator traverses composite structures via CreateIterator.
• Composite <-> Chain of Responsibility: Component-parent link supports request propagation up the tree.
• Composite <-> Flyweight: Flyweight enables sharing leaf components but requires externalizing parent references.
• Composite <-> Visitor: Visitor localizes operations otherwise distributed across Composite and Leaf classes.
• Composite <-> Command: MacroCommand is a Composite of Commands.
• Decorator <-> Composite: Both use recursive composition through a common interface. When combined, they share a common parent class.
• Decorator <-> Strategy: Decorator = skin (outside wrapping, conforms to component interface). Strategy = guts (inside delegation, can have specialized interface). Strategy preferred when Component is heavyweight.

Exam-Relevant Points

1. Composite's defining characteristic: Clients treat Leaf and Composite uniformly—no conditional type checking needed.

2. Transparency vs. safety: Add/Remove in Component = transparency. Add/Remove only in Composite = safety. GoF emphasizes transparency.

3. Decorator preserves interface: Must conform to Component interface, making decoration transparent.

4. Decorator breaks object identity: A decorated object is not identical to the original.

5. Decorator vs. inheritance: Run-time per-instance (Decorator) vs. static per-class (inheritance). Decorator avoids subclass explosion.

6. Decorator vs. Strategy: Skin vs. guts. Strategy can have a specialized interface; Decorator must match Component's interface.

7. Composite implementation issues: Parent references, component sharing (Flyweight), maximizing Component interface, child ordering (Iterator), caching (with invalidation), storage structure choice, deletion responsibility.

8. Decorator implementation issues: Interface conformance, can omit abstract Decorator class for single responsibility, keep Component lightweight.

9. Composite weakness: Overly general—can't restrict valid children via the type system.

10. Decorator weakness: Many small look-alike objects—hard to learn and debug.

---

Would you like me to retry writing this to the entries directory, or should I proceed differently?