Patterns Studio

Builder — the scenario is a textbook telescoping-constructor problem: one complex product (Computer) with many optional parts and confusing parameter order. Builder replaces the giant constructor with step-by-step calls (SetCpu(...), SetRam(...)…), so a client calls only the steps it needs, in any order, and finishes with Build(). A Director then captures the named presets — Office, Gaming, Workstation — as reusable recipes, so client code never repeats a parts list and adding a new preset touches nothing else.

Why not the others: Factory Method answers "which concrete class?" — but here there is only one product class with many configurations, so subclass-per-configuration (GamingComputer, OfficeComputer…) explodes the hierarchy for no behavioural difference. Abstract Factory creates families of related products that must match (e.g. matching GUI widgets); computer parts are picked independently, not in enforced families. Prototype solves expensive copying; Singleton solves instance count — neither is the complaint in the scenario.

public IComputerBuilder SetCpu(string cpu) { _computer.Cpu = cpu; return this; }
// ... every setter mutates, then returns this — that is what makes chaining work.

public Computer Build()
{
    var result = _computer;
    _computer = new Computer();   // reset so the builder is reusable
    return result;
}

public Computer BuildGamingPc(IComputerBuilder b)
{
    var c = b.SetCpu("Intel i7-14700K").SetRam(32).SetStorage("2TB NVMe SSD")
             .SetGpu("RTX 4070 Ti").SetOs("Windows 11")
             .AddPeripheral("144Hz Monitor").Build();
    c.BasePrice = 1800m;
    return c;
}

What to notice: the Director method reads like the marketing spec sheet — that's the win. The recipe lives in exactly one place, and the client never learns what a gaming PC contains.

(a) Decorator: RgbLighting and ExtendedWarranty wrap an IPricedComponent, adding their surcharge and description to whatever they wrap. Features stack by nesting wrappers around one machine at runtime — no GamingPcWithRgbAndWarranty subclass explosion. (b) Composite: a ComputerBundle is itself an IPricedComponent that contains children (machines, parts, other bundles); Price() recurses down the tree, so the client prices a nested package with one call, exactly as it prices one part.

// Decorator: ONE inner component, answers modified.
public override decimal Price() => Inner.Price() + 45m;

// Composite: MANY children, answers aggregated.
public decimal Price() => _items.Sum(i => i.Price());

What to notice: the two implementations are one line each, and the whole exam answer is visible in the difference between those lines — Inner. versus _items.Sum.

Both patterns rely on recursive composition against a shared component interface, but their intent differs. Decorator is about responsibilities: it wraps exactly one component and adds behaviour or state to it (RGB lighting adds 45 to that machine's price and text to its description) — the object count stays one; only its capabilities grow. Composite is about structure: it represents a part–whole hierarchy in which a group (Office Package) and an individual (a mouse, one PC) are treated uniformly — the point is aggregation over many children, not enhancement of one. Decision rule for this scenario: a requirement phrased as "add a capability to an existing computer at runtime" → Decorator; phrased as "organise computers and parts into bundles priced as one" → Composite. They also compose: a warranty-decorated machine sits inside a bundle because both are IPricedComponent. (Deeper contrast: Composite vs Decorator.)

Adapter. A TransactionServiceAdapter implements ILegacyDataSource (the target the legacy module already depends on) and wraps the new service (the adaptee). When the legacy module asks for XML, the adapter calls retrieveTransactionsJson(), converts each JSON map into a <transaction …/> element, and returns the XML string. Both existing components stay untouched — the incompatibility is absorbed entirely by one new class, which is the pattern's whole purpose: make two interfaces that already exist, and cannot change, work together.

Proxy. A TransactionServiceProxy implements the same ITransactionService interface as the real service and stands in front of it. Lazy: the proxy holds the reference but does not touch the real service until the first data request. Cache: the first result is stored; repeat calls within the window return it without a network round-trip. Protection: the proxy checks the caller's authorisation before forwarding and throws if it fails — the expensive call never even starts. Because the interface is identical, clients need zero changes; access control is a substitution, not a rewrite.

// Adapter — pure translation, no policy:
public string GetRecordsAsXml()
{
    var rows = _service.RetrieveTransactionsJson();
    var body = string.Concat(rows.Select(r =>
        $"<transaction id=\"{r["id"]}\" amount=\"{r["amount"]}\" currency=\"{r["currency"]}\"/>"));
    return $"<transactions>{body}</transactions>";
}

// Proxy — pure policy, no translation:
public List<Dictionary<string, string>> RetrieveTransactionsJson()
{
    if (!_authorized)
        throw new UnauthorizedAccessException("Caller is not authorised...");
    return _cache ??= _real.RetrieveTransactionsJson();   // lazy + cached in one line
}

What to notice: the adapter changes the shape of the call and the proxy changes the conditions of the call — and neither knows the other exists. In production you would chain them: adapter → proxy → real service.

Both are structural wrappers around the new service, but they solve orthogonal problems. Adapter changes the interface: it exposes a different contract (ILegacyDataSource) from the one it wraps, because its goal is compatibility — the legacy module and the new service could not talk at all, and the adapter translates JSON maps into the XML the legacy side demands. Proxy preserves the interface: it exposes the same contract (ITransactionService) as the real service, because its goal is access control — the conversation was already possible but too expensive and too open, so the proxy governs when the call happens (lazy), whether it happens at all (cache), and who may make it (auth). One-line test for the exam: if the client couldn't call it before, you need an Adapter; if the client could call it but shouldn't call it like that, you need a Proxy. (See also the wrapper family compared.)

Iterator. Core purpose: provide a way to access the elements of an aggregate sequentially without exposing its underlying representation. Each catalog keeps its optimal structure internally but publishes the same traversal contract, so the display module iterates identically over all three. Role mapping: Aggregate → IEnumerable<Product> (the contract every catalog implements); Concrete aggregates → ArrayCatalog, LinkedListCatalog, TreeCatalog; Iterator → the IEnumerator<Product> each GetEnumerator() returns (array index walk, node walk, category-bucket flattening); Client → the Product Display Module, which only ever writes foreach (var p in catalog). Benefits: the display module is closed for modification — supplier D with a hash map or database cursor is one new GetEnumerator(), zero display-module edits; filtering and totalling are written once against the abstraction.

// LinkedListCatalog — the iterator hides the nodes:
public IEnumerator<Product> GetEnumerator()
{
    for (var n = _head; n is not null; n = n.Next)
        yield return n.Value;
}

// The client never says "array", "node" or "tree":
public decimal TotalInventoryValue(IEnumerable<Product> catalog) => catalog.Sum(p => p.Price);

What to notice: yield return writes the Iterator pattern for you — the compiler generates the state-machine cursor class the GoF book makes you hand-roll.

The display module depends only on the abstraction IEnumerable<Product> — it is closed for modification: no traversal, filtering or totalling code mentions arrays, nodes or trees, so no supplier change can force an edit there. The system is open for extension at exactly one seam: a new supplier implements GetEnumerator() for its own structure and immediately works with every existing display feature. Consequences: (1) change amplification drops — a supplier swapping linked list for a database cursor is a one-class change; (2) testing is localised — display logic is tested once against the abstraction; (3) suppliers keep their performance-optimal internal structures, because uniformity is imposed at the traversal contract, not on the data layout. This is the same DIP-flavoured move as the OCP chapter's core example: high-level policy depends on an interface, details plug in beneath it.

Observer. Subject: StockItem, which owns the subscriber list and calls OnRestock(product, qty) on each registered observer after a restock. Observer interface: IStockObserver — the only thing the subject knows about its listeners, which is exactly what keeps email senders, push services and test doubles interchangeable. Concrete observers implement that interface and react their own way. Subscription is dynamic: Subscribe/Unsubscribe at any time, no recompilation, no subject changes.

public void Restock(int amount)
{
    Quantity += amount;
    foreach (var o in _observers.ToList())   // snapshot: safe if an observer unsubscribes mid-notify
        o.OnRestock(Name, Quantity);
}

What to notice: the snapshot (.ToList()) is the classic production defence — observers often unsubscribe from inside their own callback.

Template Method. The abstract DataPipeline.Run() is the template: it hard-codes open → Extract() → Transform() → close. Subclasses (CsvPipeline, JsonPipeline) override only the two protected abstract steps. The invariant is enforced structurally: the steps are protected, so no client can call them out of order, and Run() is the only public entry — the base class owns the order, forever.

Command. Each edit is reified as an AppendTextCommand object carrying everything needed to perform and reverse itself: the receiver (the document) and its parameters (the text). A CommandHistory holds executed commands on a stack; Ctrl-Z pops the most recent and calls its Undo(). The undo knowledge lives inside each command — the invoker only knows "pop and call Undo()", never how a particular edit reverses. Because commands are plain objects, the same mechanism queues and logs them for free.

public IReadOnlyList<string> Run()          // the template — subclasses never touch it
{
    var log = new List<string> { "open" };
    log.Add(Extract());
    log.Add(Transform());
    log.Add("close");
    return log;
}

public bool Undo()
{
    if (_history.Count == 0) return false;
    _history.Pop().Undo();                   // the command reverses itself
    return true;
}

What to notice: Run() is not virtual — that's deliberate. The pattern's power is what subclasses cannot do.

This is State, not Strategy — even though both delegate behaviour to interchangeable composed objects, which is exactly why the exam loves this trap. Three discriminators, all pointing the same way: (1) Who selects? In Strategy, the client picks an algorithm and injects it (choose a sort, choose a route). Here nobody injects "Paused" — the player transitions itself when buttons are pressed. (2) Mutual awareness: strategies are independent and ignorant of each other; states know their successors — Playing's PressPlay() installs Paused. (3) Time: a strategy is typically fixed for the interaction; state changes continuously over the object's lifetime and behaviour must track it. Decision rule: if the variants form a transition graph the object walks by itself, it's State; if they're a menu the client orders from, it's Strategy. (Full contrast: Strategy vs State.)

Factory Method. Define an abstract creator (TicketCreator, or per-channel creators) whose factory method CreateTicket() returns the abstract Ticket; concrete creators (VipTicketCreator, EarlyBirdTicketCreator…) override it to instantiate their type. Client code holds only TicketCreator/Ticket references, so adding ETicket is one new product + one new creator — existing clients are untouched: creation obeys OCP. Builder would over-engineer (tickets aren't many-optional-part assemblies) and Abstract Factory is only warranted if tickets came in enforced matched families.

Composite. Component: IVenueComponent (e.g. FreeSeats(), Price()); Composite: Zone/Section holding child components and recursing; Leaf: Seat answering for itself. The tree-with-uniform-treatment phrasing ("a zone can contain other zones as well as seats") is the Composite signature — the same signal as shelves/sections in the past paper's library.

(i) Observer — subject: Event (holds the waitlist, publishes OnTicketsReleased); observer interface: IWaitlistObserver; concrete observers: fan notifier channels (app push, email). Dynamic subscribe/unsubscribe is the tell. (ii) Template Method — abstract CheckoutProcess.Run() fixes validate → reserve → pay → issue; subclasses (VipCheckout, ETicketCheckout) override only the varying steps (notably IssueTickets()). Same pairing the past paper's library question rewards for notify-on-availability and the fixed borrowing procedure.

The Factory Method isolates which ticket class exists, so the Template Method checkout can issue tickets through the abstract Ticket without a single if (type == ...) — new ticket types slot into an unchanged checkout. The Composite venue lets a Ticket hold one Seat leaf while pricing and availability roll up zone trees of any depth — checkout reserves a seat with the same call whether the fan bought one seat or a box. The Observer keeps Event ignorant of notification channels, so releasing returned tickets (a checkout cancellation, say) triggers waitlist alerts without coupling sales code to email or push infrastructure. Each pattern owns one axis of change — ticket variety, venue shape, notification fan-out, checkout steps — which is why the design stays open to the SRS's stated futures (E-Tickets, new zones, new channels, VIP perks) with only additive changes. (Compare the worked fusion in chapter 6.)

Encapsulation: _stock is private with no public setter; all mutation flows through Restock()/ReduceStock(), which throw InvalidStockException on anything that would go negative — the invariant lives inside Product, uncircumventable. Abstraction: the abstract Product declares IsSellable(today) and ProcessSale(today) — the whole contract the cart needs. Polymorphism: each subclass answers differently — PerishableProduct checks expiry, DigitalProduct returns a fresh DL- code and leaves stock untouched. The cart calls the same two methods on everything, so no type-checks: the variation is inside the types, not in the caller.

protected void ReduceStock(int amount)
{
    if (amount <= 0) throw new InvalidStockException("Reduction must be positive.");
    if (_stock - amount < 0) throw new InvalidStockException($"Stock for '{Name}' cannot go negative.");
    _stock -= amount;
}

What to notice: ReduceStock is protected — even subclasses go through the validated path, and external code has no path at all.

Interface Segregation kills IPeripheral: a scanner cannot print, so a fat interface forces degenerate implementations — split into IBarcodeReader and IReceiptService so each driver implements only what it can honour. Dependency Injection (applying DIP) removes the internal new: the terminal receives both drivers via its constructor and holds them as interface fields. Runtime swap then falls out for free — SwapHardware(printer: new EmailReceipt(...)) reassigns a field; the terminal's logic, typed against the interfaces, never notices.

Strategy. Interface: IPaymentStrategy.ProcessPayment(amount); concrete strategies: CashPayment, CreditCardPayment, StoreCreditPayment; context: PaymentProcessor, whose Checkout simply delegates. OCP: CryptoPay is a new class implementing the interface — the processor's code is provably untouched (the lab's Step8_Ocp_* test drops in a fake crypto strategy and it just works). LSP: every strategy must be substitutable behind the interface — the terminal calls ProcessPayment without knowing which is active, so no strategy may strengthen preconditions or surprise the caller beyond the declared contract. Note this is client-chosen algorithm selection — Strategy, not State: the payment method doesn't transition itself (the trap from Lab 4 again).

public decimal CalculateFinalPrice(CartInfo cart)
{
    var total = cart.Subtotal;
    foreach (var rule in _rules)          // composition: a LIST of rules,
        total = rule.Apply(total, cart);  // applied in order, stacking naturally
    return Math.Max(total, 0m);
}

What to notice: discount stacking is just iteration order. The inheritance alternative (HappyHourCart, LoyaltyHappyHourCart…) needs a subclass per combination — combinatorial explosion is the exam keyword.

Inheritance encodes each combination as a class: 5 stackable rules means up to 2⁵ = 32 cart subclasses (order-sensitive stacking is worse still), and adding rule #6 doubles it — modification, not extension. Composition holds a List<IDiscountRule>: 5 rules = 5 small classes; rule #6 is one new class and zero edits elsewhere (OCP); any subset stacks by adding to the list. Runtime: the composed design reconfigures per transaction — Happy Hour switches on at 5 PM by adding a rule object — while the inheritance design fixed the cart's class at construction. Same verdict the past paper's Q3 demands for payment methods: favour object composition over class inheritance whenever behaviours combine or change at runtime.