Structural Design Patterns

Creational patterns (Chapter 3) were about making objects. Structural patterns are about composing them — how classes and objects fit together into larger structures that stay flexible, so you can add capabilities or swap parts without rewriting everything. Seven patterns, one big idea: prefer wiring small objects together over building one giant rigid class.

The big idea

A structural pattern answers the question: "I have several classes/objects — how do I arrange them so the whole is flexible?" The Gang of Four split these into two flavours:

• Structural class patterns use inheritance to compose interfaces or implementations (one class inherits from several). Static — fixed at compile time.
• Structural object patterns compose objects — one object holds a reference to another and delegates work to it. The killer advantage: you can change the composition at run-time, which pure inheritance can never do.

Jump to a pattern:

The seven structural patterns

Adapter structural a.k.a. Wrapper

Intent — one line: convert the interface a class has into the interface a client expects, so two things that were never designed to work together suddenly can.

The problem

You're building a stock-market monitoring app. It downloads quotes in XML and draws charts. Later you buy a slick third-party analytics library to spot trends — but it only accepts JSON. You can't edit the library: you don't have its source, and changing it would break everyone else who uses it. Your XML data and the library simply speak different languages.

// The analytics library, which you cannot change:
public class SmartAnalytics
{
    public string Analyze(IJsonSource source) // wants JSON
        => $"Trend for {source.GetJson()}";
}

// Your existing data source speaks XML:
public class XmlStockFeed
{
    public string GetXml() => "<stock price='142.5'/>";
}

var feed = new XmlStockFeed();
var analytics = new SmartAnalytics();
analytics.Analyze(feed); // ✖ won't compile:
                         //   XmlStockFeed is not an IJsonSource

// One small class that IS a JSON source
// but WRAPS the XML feed and translates.
public class XmlToJsonAdapter : IJsonSource
{
    private readonly XmlStockFeed _feed;
    public XmlToJsonAdapter(XmlStockFeed feed) => _feed = feed;

    public string GetJson()
    {
        string xml = _feed.GetXml();      // ask adaptee
        // ...real code parses XML here...
        return "{ \"price\": 142.5 }";    // hand back JSON
    }
}

var adapter = new XmlToJsonAdapter(new XmlStockFeed());
analytics.Analyze(adapter); // ✔ library is happy

Solution — the full cast

Four roles: the Target (interface the client wants — IJsonSource), the Adaptee (the existing, incompatible class — XmlStockFeed), the Adapter (translator), and the Client (SmartAnalytics). Now — there are two ways to build the adapter, and the slides call this out explicitly.

public interface IJsonSource            // Target
{
    string GetJson();
}

public class XmlStockFeed               // Adaptee (unchangeable)
{
    public string GetXml() => "<stock price='142.5'/>";
}

public class XmlToJsonAdapter : IJsonSource   // Object adapter
{
    private readonly XmlStockFeed _feed;      // ← composition
    public XmlToJsonAdapter(XmlStockFeed feed) => _feed = feed;
    public string GetJson() => Translate(_feed.GetXml());

    private static string Translate(string xml) => "{ \"price\": 142.5 }";
}

// Hybrid "class adapter": inherit the adaptee, implement the target.
public class XmlToJsonClassAdapter : XmlStockFeed, IJsonSource
{
    // GetXml() is inherited directly — no field, no delegation object.
    public string GetJson() => Translate(GetXml());

    private static string Translate(string xml) => "{ \"price\": 142.5 }";
}

When to use it — and the costs

Bridge structural

Intent — one line: when a class varies in two independent directions at once, split it into two separate hierarchies — an abstraction and an implementation — and connect them with a reference (the "bridge"), so each direction grows on its own.

The problem — combinatorial explosion

Say you have a Shape class. You add two shapes: Circle and Square. Fine. Now the shapes need colours. The tempting move is to subclass:

public abstract class Shape { }

public class RedCircle  : Shape { }
public class BlueCircle : Shape { }
public class RedSquare  : Shape { }
public class BlueSquare : Shape { }
// 2 shapes × 2 colours = 4 classes

public interface IColor { string Fill(); }          // implementation side
public class Red  : IColor { public string Fill() => "red"; }
public class Blue : IColor { public string Fill() => "blue"; }

public abstract class Shape                          // abstraction side
{
    protected readonly IColor color;                 // ← the bridge
    protected Shape(IColor color) => this.color = color;
    public abstract string Draw();
}
public class Circle : Shape
{
    public Circle(IColor c) : base(c) { }
    public override string Draw() => $"Circle filled {color.Fill()}";
}

public interface IDevice                 // Implementation
{
    int Volume { get; set; }
    string Name { get; }
}
public class Radio : IDevice { public int Volume { get; set; } public string Name => "Radio"; }
public class Tv    : IDevice { public int Volume { get; set; } public string Name => "TV"; }

public class BasicRemote                  // Abstraction (holds an IDevice = the bridge)
{
    protected readonly IDevice device;
    public BasicRemote(IDevice device) => this.device = device;
    public void VolumeUp()   { device.Volume++; Console.WriteLine($"{device.Name}: {device.Volume}"); }
    public void VolumeDown() { device.Volume--; Console.WriteLine($"{device.Name}: {device.Volume}"); }
}

public class AdvancedRemote : BasicRemote  // Refined abstraction — new control logic, same devices
{
    public AdvancedRemote(IDevice device) : base(device) { }
    public void Mute() { device.Volume = 0; Console.WriteLine($"{device.Name}: muted"); }
}

// Client links an abstraction to an implementation:
var remote = new AdvancedRemote(new Tv());
remote.VolumeUp();
remote.Mute();

Composite structural a.k.a. Object Tree

Intent — one line: arrange objects into a tree and let the client treat a single object (a leaf) and a whole group of objects (a composite) through the same interface.

The problem

You're building an ordering system. An order holds products, but also boxes — and a box can hold products and other boxes, nested arbitrarily. How do you compute the total price?

decimal TotalPrice(object item)
{
    if (item is Product p) return p.Price;
    if (item is Box b)
    {
        decimal sum = 0;
        foreach (var child in b.Items)
            sum += TotalPrice(child); // recurse, re-checking types
        return sum;
    }
    throw new InvalidOperationException("unknown item");
}

public interface IOrderComponent { decimal GetPrice(); }

public class Product : IOrderComponent          // Leaf
{
    public decimal Price { get; init; }
    public decimal GetPrice() => Price;
}

public class Box : IOrderComponent              // Composite
{
    private readonly List<IOrderComponent> _items = new();
    public void Add(IOrderComponent c) => _items.Add(c);
    public decimal GetPrice() => _items.Sum(c => c.GetPrice()); // delegates down
}

The three roles: Component (the shared interface — IOrderComponent), Leaf (no children, does the real work — Product), and Composite / Container (has children, delegates — Box). Here it is as a file system, which we'll drive in the demo:

public interface IFileNode
{
    string Name { get; }
    long GetSize();               // both leaves and folders answer this
}

public class FileLeaf : IFileNode                 // Leaf
{
    public string Name { get; }
    private readonly long _size;
    public FileLeaf(string name, long size) { Name = name; _size = size; }
    public long GetSize() => _size;
}

public class Folder : IFileNode                   // Composite
{
    public string Name { get; }
    private readonly List<IFileNode> _children = new();
    public Folder(string name) { Name = name; }
    public void Add(IFileNode node) => _children.Add(node);
    public long GetSize() => _children.Sum(c => c.GetSize()); // recurse
}

Decorator structural a.k.a. Wrapper

Intent — one line: add responsibilities to an individual object at run-time by wrapping it in another object that shares its interface — as many layers deep as you like.

The problem

A coffee shop sells an espresso, and customers add milk, sugar, whipped cream, oat milk… in any combination. You need a price and a description for each order. The obvious approach — a subclass per combination — detonates.

public class Espresso { }
public class EspressoWithMilk { }
public class EspressoWithMilkAndSugar { }
public class EspressoWithMilkSugarWhip { }
public class EspressoWithOatMilk { }
// ...4 add-ons → up to 2⁴ = 16 classes,
//    and every new add-on DOUBLES the count.

IBeverage order = new Espresso();      // 2.50
order = new Milk(order);               // +0.50
order = new Sugar(order);              // +0.25
order = new Whip(order);               // +0.75
Console.WriteLine($"{order.Description()} = {order.Cost():C}");
// Espresso, milk, sugar, whip = $4.00

public interface IBeverage                 // Component
{
    string Description();
    decimal Cost();
}

public class Espresso : IBeverage          // Concrete component
{
    public string Description() => "Espresso";
    public decimal Cost() => 2.50m;
}

// Base decorator: itself an IBeverage, WRAPS an IBeverage.
public abstract class BeverageDecorator : IBeverage
{
    protected readonly IBeverage inner;
    protected BeverageDecorator(IBeverage inner) => this.inner = inner;
    public virtual string Description() => inner.Description();
    public virtual decimal Cost()       => inner.Cost();
}

public class Milk : BeverageDecorator
{
    public Milk(IBeverage b) : base(b) { }
    public override string Description() => inner.Description() + ", milk";
    public override decimal Cost()       => inner.Cost() + 0.50m;
}

public class Sugar : BeverageDecorator
{
    public Sugar(IBeverage b) : base(b) { }
    public override string Description() => inner.Description() + ", sugar";
    public override decimal Cost()       => inner.Cost() + 0.25m;
}
// Whip, OatMilk, Caramel… all follow the identical shape.

// Read → Decrypt → Decompress, all through one Stream interface:
using FileStream file = File.OpenRead("data.bin");     // Concrete component
using var decrypt     = new CryptoStream(file, decryptor, CryptoStreamMode.Read);
using var decompress  = new GZipStream(decrypt, CompressionMode.Decompress);
using var buffered    = new BufferedStream(decompress); // adds buffering

// The consumer just sees a Stream — it has no idea it's 4 layers deep.
using var reader = new StreamReader(buffered);
string text = reader.ReadToEnd();

Facade structural

Intent — one line: put a single, simplified interface in front of a complicated subsystem, so clients push one button instead of wiring a dozen parts together in the right order.

The problem

To make a pizza, six subsystems must run in the right order: prepare dough, add sauce, add toppings, bake in the oven, take payment, dispatch delivery. If every client does this by hand, your business logic gets welded to the internals of six classes.

var dough   = new DoughStation();
var sauce   = new SauceStation();
var oven    = new Oven();
var payment = new PaymentGateway();
var courier = new DeliveryService();

var pizza = dough.Prepare("thin");
sauce.Apply(pizza, "tomato");
oven.Preheat(220);                 // forget this → raw pizza
oven.Bake(pizza, minutes: 12);
payment.Charge(customer, 14.99m);  // wrong order → deliver unpaid
courier.Dispatch(pizza, address);

public class PizzaShopFacade
{
    private readonly DoughStation _dough = new();
    private readonly SauceStation _sauce = new();
    private readonly Oven _oven = new();
    private readonly PaymentGateway _payment = new();
    private readonly DeliveryService _courier = new();

    public void OrderPizza(string kind, Customer c, string addr)
    {
        var pizza = _dough.Prepare("thin");
        _sauce.Apply(pizza, "tomato");
        _oven.Preheat(220);
        _oven.Bake(pizza, 12);
        _payment.Charge(c, 14.99m);
        _courier.Dispatch(pizza, addr);
    }
}

new PizzaShopFacade().OrderPizza("pepperoni", customer, address);

Flyweight structural

Intent — one line: when you need a huge number of similar objects, share the parts they have in common instead of duplicating them, so memory stays small. Caching is one implementation mechanism a flyweight factory happens to use — it isn't what the pattern is named for or defined by.

The problem

You're rendering a forest with a million trees. Each Tree stores its position and its species name, colour, and a big texture/mesh. But there are only three species — so you're storing the same heavy texture a million times.

public class Tree                     // ~1 KB each (texture + mesh inline)
{
    public int X, Y;                  // unique  (extrinsic)
    public string Species;            // repeated (intrinsic)
    public string Color;              // repeated
    public byte[] Texture;            // repeated — the expensive part!
}

var forest = new List<Tree>();
for (int i = 0; i < 1_000_000; i++)
    forest.Add(new Tree { X = rx(), Y = ry(),
        Species = "Oak", Color = "green", Texture = LoadOakTexture() });
// 1,000,000 copies of the SAME oak texture in RAM.

// Intrinsic state — created once per species, shared by all.
public class TreeType                          // Flyweight
{
    private readonly byte[] _texture;          // private defensive copy — never handed out raw

    public string Species { get; }
    public string Color { get; }
    // Any holder of a raw byte[] could mutate it and corrupt every tree that
    // shares this flyweight, so we only ever expose a read-only view.
    public ReadOnlyMemory<byte> Texture => _texture;

    public TreeType(string s, string c, byte[] t) => (Species, Color, _texture) = (s, c, (byte[])t.Clone());
    public void Draw(int x, int y) => Console.WriteLine($"Drawing {Species} at ({x},{y}) with shared texture");
}

public class Tree                              // ~32 bytes: 16-byte header + 2 ints + a reference
{
    public int X, Y;                           // extrinsic
    private readonly TreeType _type;           // shared reference
    public Tree(int x, int y, TreeType type) => (X, Y, _type) = (x, y, type);
    public void Draw() => _type.Draw(X, Y);
}

The Flyweight Factory guarantees sharing: it hands back an existing flyweight if one already exists for that intrinsic state, and only creates a new one otherwise. Texture is intrinsic too, so it belongs inside the cache key's inputs — the factory loads it itself from the species, rather than accepting it as a separate parameter that could vary independently and silently break sharing.

public class TreeFactory
{
    private readonly Dictionary<string, TreeType> _cache = new();

    public TreeType GetTreeType(string species, string color)
    {
        string key = $"{species}:{color}";
        if (!_cache.TryGetValue(key, out var type))
            _cache[key] = type = new TreeType(species, color, LoadTexture(species)); // create once
        return type;                                                                   // otherwise share
    }

    private static byte[] LoadTexture(string species) => /* load from disk/atlas */ new byte[1024];
}

Proxy structural

Intent — one line: provide a stand-in with the same interface as a real object, so the stand-in can control access to it — delaying its creation, checking permissions, caching, or logging.

The problem

A gallery shows high-resolution images. Each RealImage loads its (large) file from disk the moment it's created — so opening the gallery loads every image up front, even the ones the user never scrolls to. Slow start, wasted memory.

public class RealImage : IImage
{
    private readonly string _file;
    public RealImage(string file)
    {
        _file = file;
        LoadFromDisk(file);           // heavy — happens immediately
    }
    public void Display() => Console.WriteLine($"Showing {_file}");
    private void LoadFromDisk(string f) => Console.WriteLine($"Loading {f} (4 MB)...");
}

// Opening the gallery loads ALL 200 images now,
// even though only ~5 are on screen.
var gallery = files.Select(f => new RealImage(f)).ToList();

public class ProxyImage : IImage        // same interface as RealImage
{
    private readonly string _file;
    private RealImage? _real;           // created on first use
    public ProxyImage(string file) => _file = file;

    public void Display()
    {
        _real ??= new RealImage(_file); // load the heavy object ONCE, on demand
        _real.Display();                // then cache it for next time
    }
}

// Cheap to create 200 proxies; each loads only when first shown.
var gallery = files.Select(f => new ProxyImage(f)).ToList();

Structural patterns at a glance

Check yourself