Composite Design Pattern

public interface Component {
    Money monthlyCost();
    String name();
}

/** Leaf: knows its own cost, has no children. */
public record Service(String name, Money monthlyCost) implements Component {}

/** Composite: same interface, answers by asking its children. */
public final class ResourceGroup implements Component {

    private final String name;
    private final List<Component> children = new ArrayList<>();

    public ResourceGroup(String name) { this.name = name; }

    // add() lives HERE, not on Component — the "safe" side of GoF's trade-off.
    public ResourceGroup add(Component child) {
        children.add(child);
        return this;
    }

    @Override public String name() { return name; }

    @Override public Money monthlyCost() {
        return children.stream()
                       .map(Component::monthlyCost)   // never asks what kind of child
                       .reduce(Money.ZERO, Money::plus);
    }
}

// Build any shape; ask one question:
Component account = new ResourceGroup("production")
        .add(new ResourceGroup("analytics")
                .add(new Service("ec2", Money.gbp(320)))
                .add(new Service("s3", Money.gbp(85))))
        .add(northwindSubAccount);        // an entire tree, added like a leaf

Money total = account.monthlyCost();      // depth is not the caller's problem

from __future__ import annotations

from dataclasses import dataclass, field
from typing import Protocol


class Component(Protocol):
    name: str
    def monthly_cost(self) -> Decimal: ...


@dataclass(frozen=True)
class Service:
    name: str
    cost: Decimal

    def monthly_cost(self) -> Decimal:
        return self.cost


@dataclass
class ResourceGroup:
    name: str
    children: list[Component] = field(default_factory=list)

    def add(self, child: Component) -> ResourceGroup:
        self.children.append(child)
        return self

    def monthly_cost(self) -> Decimal:
        return sum((c.monthly_cost() for c in self.children), Decimal(0))


# Two Python-specific warnings worth having before production:
#
# 1. Recursion depth. CPython's default limit is 1000 frames, so a genuinely
#    deep tree (a filesystem, a category graph) raises RecursionError. Convert
#    the walk to an explicit stack if depth is unbounded.
#
# 2. `sum` needs the typed zero. `sum(...)` starts at the int 0 and adding
#    Decimal to int works, but the same code over a Money class would not —
#    pass the identity explicitly, as above.

#include <memory>
#include <numeric>
#include <vector>

class Component {
public:
    virtual ~Component() = default;
    virtual Money monthlyCost() const = 0;
    virtual std::string_view name() const = 0;
};

class Service final : public Component {
public:
    Service(std::string name, Money cost) : name_(std::move(name)), cost_(cost) {}
    Money monthlyCost() const override { return cost_; }
    std::string_view name() const override { return name_; }
private:
    std::string name_;
    Money cost_;
};

class ResourceGroup final : public Component {
public:
    explicit ResourceGroup(std::string name) : name_(std::move(name)) {}

    // unique_ptr: the composite OWNS its children, and destroying the root
    // destroys the whole tree exactly once. This is the ownership question
    // every C++ composite has to answer before anything else.
    ResourceGroup& add(std::unique_ptr<Component> child) {
        children_.push_back(std::move(child));
        return *this;
    }

    Money monthlyCost() const override {
        return std::accumulate(
            children_.begin(), children_.end(), Money{0},
            [](Money acc, const auto& c) { return acc + c->monthlyCost(); });
    }

    std::string_view name() const override { return name_; }

private:
    std::string name_;
    std::vector<std::unique_ptr<Component>> children_;
};

// If children can be shared between trees, shared_ptr — but then watch for
// cycles, which leak. A parent back-pointer must be weak_ptr, never shared_ptr.

public interface IComponent
{
    string Name { get; }
    decimal MonthlyCost();
}

public sealed record Service(string Name, decimal Cost) : IComponent
{
    public decimal MonthlyCost() => Cost;
}

public sealed class ResourceGroup(string name) : IComponent
{
    private readonly List<IComponent> _children = [];

    public string Name => name;

    public ResourceGroup Add(IComponent child)
    {
        _children.Add(child);
        return this;
    }

    public decimal MonthlyCost() => _children.Sum(c => c.MonthlyCost());
}

// LINQ makes every other tree question a one-liner once the shape exists —
// and note that a recursive enumerator gives you the whole tree flattened,
// which is where Composite and Iterator meet:
//
//     public IEnumerable<IComponent> Descendants() =>
//         _children.SelectMany(c =>
//             c is ResourceGroup g ? g.Descendants().Prepend(c) : [c]);
//
//     account.Descendants().Where(c => c.MonthlyCost() > 100);

// The DOM is the composite tree every web developer already knows: an element
// contains nodes, and an element IS a node. This is the same shape.

const service = (name, cost) => ({
  name,
  monthlyCost: () => cost,
})

const group = (name, children = []) => ({
  name,
  children,
  add(child) {
    children.push(child)
    return this
  },
  monthlyCost: () => children.reduce((sum, c) => sum + c.monthlyCost(), 0),
})

const account = group('production')
  .add(group('analytics').add(service('ec2', 320)).add(service('s3', 85)))
  .add(northwindSubAccount)

account.monthlyCost()

// Money in floats is the trap here, not the tree: 0.1 + 0.2 !== 0.3, and a
// recursive sum compounds the error at every level. Keep costs in integer
// pence and format at the edge — or use BigInt for genuinely large trees.

package billing

// No inheritance, so leaf and composite simply both satisfy the interface —
// which is arguably the clearest statement of what Composite actually requires.

type Component interface {
	Name() string
	MonthlyCost() Money
}

type Service struct {
	name string
	cost Money
}

func (s Service) Name() string     { return s.name }
func (s Service) MonthlyCost() Money { return s.cost }

type Group struct {
	name     string
	children []Component
}

func (g *Group) Add(c Component) *Group {
	g.children = append(g.children, c)
	return g
}

func (g *Group) Name() string { return g.name }

func (g *Group) MonthlyCost() Money {
	var total Money
	for _, c := range g.children {
		total += c.MonthlyCost()   // never type-switches on the child
	}
	return total
}

// errors.Join is a composite hiding in the standard library: it returns a single
// error that wraps many, and errors.Is walks the tree for you — so calling code
// treats "one failure" and "nine failures" through exactly the same interface.

interface Component {
  readonly name: string
  monthlyCost(): number
}

class Service implements Component {
  constructor(readonly name: string, private readonly cost: number) {}
  monthlyCost(): number { return this.cost }
}

class ResourceGroup implements Component {
  private readonly children: Component[] = []

  constructor(readonly name: string) {}

  add(child: Component): this {
    this.children.push(child)
    return this
  }

  monthlyCost(): number {
    return this.children.reduce((sum, c) => sum + c.monthlyCost(), 0)
  }
}

// TypeScript offers a genuine alternative the OO languages don't, and for a
// FIXED set of node types it is usually better: a discriminated union plus an
// exhaustive switch. The compiler then proves you handled every node kind, and
// adding a kind turns every walk into a compile error instead of a silent gap.

type Node =
  | { kind: 'service'; name: string; cost: number }
  | { kind: 'group'; name: string; children: Node[] }

const monthlyCost = (node: Node): number => {
  switch (node.kind) {
    case 'service': return node.cost
    case 'group':   return node.children.reduce((s, c) => s + monthlyCost(c), 0)
  }
}

// Use the classes when node types are open-ended and callers add their own;
// use the union when the set is closed and the OPERATIONS keep growing —
// which is the same trade-off the Visitor pattern exists to manage.