Good Design & SOLID

Chapter 1 gave you the mechanics of objects — inheritance, polymorphism, composition. This chapter is about judgement: what makes one design better than another. You'll learn the two goals every design serves (reuse and extensibility), three pre-SOLID design principles, the five SOLID principles — with the deepest treatment reserved for Liskov Substitution — and finally what a design pattern actually is, which sets up chapters 3–5.

What does "good design" even mean?

Good design is design that stays cheap to change. That sounds underwhelming until you realise that almost everything that goes wrong in software projects — blown deadlines, fragile releases, "we can't touch that module" folklore — is the cost of change growing out of control. The lecture slides boil good design down to two measurable features: code reuse and extensibility.

Code reuse — why copy-paste is debt

Cost and time are the two most valuable metrics in software development. Less development time means entering the market before competitors; lower cost means more budget left for everything else. Reusing code you already have is the most direct way to save both — and design patterns exist largely to make components flexible enough to be reusable.

The enemy of reuse is copy-paste. Copying a block of code feels free — it takes three seconds. But you haven't reused the code, you've cloned it, and every clone is a debt you now owe:

• Bugs multiply. Fix a bug in one copy and it silently survives in the other four. Nobody remembers where the copies are.
• Changes multiply. A new requirement ("tax rules changed") must be applied to every clone, consistently, or the system disagrees with itself.
• Clones drift. Each copy gets edited slightly differently over time, so eventually you can't even tell whether the differences are intentional.

Extensibility — change is the only constant

Requirements will change. Your design's job is to absorb that change without breaking. Why is change guaranteed?

• We understand a problem better once we start solving it. The design you'd produce after six months of building is always better than the one you produced on day one — so day-one designs get revised.
• The world around the software changes. New payment providers appear, tax law changes, the business pivots, an OS update breaks an assumption. None of this is your code's fault; it must cope anyway.
• Success creates change. If the product works, users ask for more. The reward for shipping version 1 is the change requests for version 2.

Seasoned developers therefore design for change: they ask "when this requirement moves, how many files do I have to edit, and how scared will I be while editing them?" Good design practice — especially reusing design patterns that others have battle-tested on similar problems — reduces the time and cost of maintaining software.

Principle 1 — Encapsulate what varies

Identify the aspects of your application that vary and separate them from what stays the same. The goal is to minimise the effect caused by changes: isolate the volatile parts of the program into independent modules, so that when they change (and they will), the rest of the code doesn't even notice.

The slides show this at two levels: method level and class level. Let's walk both, using the pizza-chain scenario from your tutorial (Tutorial 17): a global pizza company where every country has a different tax rule and a different cooking requirement.

Encapsulate at method level

Here's the naive version. Watch what happens inside GetOrderTotal:

public class PizzaOrder
{
    public decimal GetOrderTotal(decimal subtotal, string country)
    {
        decimal total = subtotal;

        // Tax logic — THIS is the part that keeps changing
        if (country == "US")
            total += subtotal * 0.10m;   // US sales tax
        else if (country == "UK")
            total += subtotal * 0.20m;   // UK VAT
        // ...next month: Italy, Japan, Australia...

        return total;
    }
}

public class PizzaOrder
{
    public decimal GetOrderTotal(decimal subtotal, string country)
    {
        // The STABLE part: totalling never changes
        return subtotal + subtotal * GetTaxRate(country);
    }

    // The VOLATILE part now lives behind one named seam
    private decimal GetTaxRate(string country) => country switch
    {
        "US" => 0.10m,
        "UK" => 0.20m,
        _    => 0m
    };
}

Encapsulate at class level

Method extraction works until the varying part grows. Real tax calculation needs country + state + province + product category + tax-exemption rules… Soon GetTaxRate and its helper fields dominate the class, and PizzaOrder has quietly become a tax engine that also happens to total pizzas. Time to promote the variation to its own class:

public class TaxCalculator
{
    public decimal GetTaxRate(string country, string state, string product)
    {
        // All the messy, ever-changing tax law lives HERE and only here
        if (country == "US")  return GetUsTax(state);
        if (country == "UK")  return 0.20m;
        return 0m;
    }

    private decimal GetUsTax(string state) => state == "CA" ? 0.0725m : 0.06m;
}

public class PizzaOrder
{
    private readonly TaxCalculator _tax = new();   // delegate the volatile job

    public decimal GetOrderTotal(decimal subtotal, string country, string state)
        => subtotal + subtotal * _tax.GetTaxRate(country, state, "food");
}

The pattern in the pattern: once the variation lives in its own class, the next natural step is to define an interface for it (ITaxStrategy) and let different implementations be swapped in — UsTax, UkTax, EuTax. At that point you have independently invented the Strategy pattern. The tutorial's full solution does exactly this, with a TaxStrategy and a CookingStrategy (wood-fire vs electric oven) plugged into a PizzaOrder that never changes again — even when a DiscountStrategy is added later.

Principle 2 — Program to an interface, not an implementation

Depend on abstractions, not on concrete classes. Before unpacking that, one important clarification:

The slides illustrate the idea with a cat: a cat that can eat any food is more flexible than a cat that can only eat sausage. Concretely:

public class Cat
{
    // This cat can ONLY eat sausage. New food = edit Cat.
    public void Eat(Sausage food)
    {
        Console.WriteLine($"Eating {food.Name}: +{food.Nutrition} energy");
    }
}

public interface IFood
{
    string Name { get; }
    int Nutrition { get; }
}

public class Sausage : IFood { /* ... */ }
public class Fish    : IFood { /* ... */ }

public class Cat
{
    // This cat eats anything that fulfils the IFood contract
    public void Eat(IFood food)
    {
        Console.WriteLine($"Eating {food.Name}: +{food.Nutrition} energy");
    }
}

The slides give a four-step recipe for setting up this kind of flexible collaboration between two classes:

1. Determine what exactly one object needs from the other — which methods does it actually call?
2. Describe those methods in a new interface (or abstract class).
3. Make the dependency class implement that interface.
4. Make the dependent class use the interface rather than the concrete class.

The worked example: a software company

The slides develop this principle into a three-stage refactor that's worth following closely, because its final stage is your first real design pattern. Scenario: a Company that creates software using different kinds of employees.

public class Designer
{
    public void DesignArchitecture() => Console.WriteLine("Designing architecture...");
}
public class Programmer
{
    public void WriteCode() => Console.WriteLine("Writing code...");
}
public class Tester
{
    public void TestSoftware() => Console.WriteLine("Testing software...");
}

public class Company
{
    public void CreateSoftware()
    {
        // Coupled to THREE concrete classes AND their individual method names
        var d = new Designer();   d.DesignArchitecture();
        var p = new Programmer(); p.WriteCode();
        var t = new Tester();     t.TestSoftware();
    }
}

public interface IEmployee
{
    void DoWork();
}

public class Designer : IEmployee
{
    public void DoWork() => Console.WriteLine("Designing architecture...");
}
public class Programmer : IEmployee
{
    public void DoWork() => Console.WriteLine("Writing code...");
}
public class Tester : IEmployee
{
    public void DoWork() => Console.WriteLine("Testing software...");
}

public class Company
{
    public void CreateSoftware()
    {
        var employees = new List<IEmployee>
        {
            new Designer(), new Programmer(), new Tester()   // still coupled here!
        };
        foreach (var e in employees)
            e.DoWork();                    // polymorphism does the routing
    }
}

public abstract class Company
{
    // The stable, reusable business process — written ONCE
    public void CreateSoftware()
    {
        foreach (var e in GetEmployees())
            e.DoWork();
    }

    // The varying part: WHICH employees? Subclasses decide.
    protected abstract IEnumerable<IEmployee> GetEmployees();
}

public class GameDevCompany : Company
{
    protected override IEnumerable<IEmployee> GetEmployees()
        => new IEmployee[] { new Designer(), new Programmer(), new Tester() };
}

public class OutsourcingCompany : Company
{
    protected override IEnumerable<IEmployee> GetEmployees()
        => new IEmployee[] { new Programmer(), new Tester() };
}

Principle 3 — Favour composition over inheritance

Inheritance is the most obvious way to reuse code — and the most expensive one to walk back. When two classes share code, the reflex is: make a common base class and move the shared code up. Easy. Unfortunately, inheritance comes with caveats that often become apparent only after your program has tons of classes and changing anything is hard. The slides list five:

The combinatorial explosion, drawn

The slides' example: a catalogue app for a vehicle manufacturer. The company makes cars and trucks (cargo type); each can be electric or gas (engine); each has manual controls or autopilot (navigation). Model each combination as a subclass and count what happens:

Worse than the count: the same engine code is duplicated in ElectricCarAutopilot and ElectricTruckManual — inheritance promised reuse and delivered copy-paste with extra steps.

The fix: delegate behaviours to component objects

Composition flips "is-a" into "has-a". Instead of a transport being an electric-autopilot-car, a transport has an engine and has a driver, and delegates behaviour to them (see delegation, chapter 1). Each dimension of variation becomes a small family of components:

// Any combination, assembled on demand — no subclass zoo:
var evTruck = new Transport(new ElectricEngine(), new Autopilot());
evTruck.Deliver("solar panels");

public interface IEngine  { void Move(); }
public interface IDriver  { void Navigate(); }

public class CombustionEngine : IEngine
{
    public void Move() => Console.WriteLine("Burning gas, moving...");
}
public class ElectricEngine : IEngine
{
    public void Move() => Console.WriteLine("Silently gliding on battery...");
}
public class HumanDriver : IDriver
{
    public void Navigate() => Console.WriteLine("Human picks the route.");
}
public class Autopilot : IDriver
{
    public void Navigate() => Console.WriteLine("AI computes optimal route.");
}

public class Transport
{
    private IEngine _engine;
    private IDriver _driver;

    public Transport(IEngine engine, IDriver driver)
        => (_engine, _driver) = (engine, driver);

    // Bonus: behaviours can be REPLACED AT RUNTIME —
    // impossible with inheritance, where the class is fixed at construction.
    public void SwapEngine(IEngine newEngine) => _engine = newEngine;

    public void Deliver(string cargo)
    {
        _driver.Navigate();
        _engine.Move();
        Console.WriteLine($"Delivering {cargo}.");
    }
}

Same disease, business flavour: the payment class explosion

Your tutorial (Tutorial 14) shows the identical problem in a payment system — worth seeing because it looks "enterprisey" rather than academic:

public abstract class Payment { /* ... */ }

public class CreditCardEmailPayment : Payment { /* ... */ }
public class CreditCardSmsPayment   : Payment { /* ... */ }
public class PayPalEmailPayment     : Payment { /* ... */ }
public class PayPalSmsPayment       : Payment { /* ... */ }

// Business: "add Crypto payments and Slack notifications"
// → SIX new classes to cover the new combinations. And the
// email-sending code is already duplicated in two classes.

// "Add Crypto + Slack" = TWO small classes. Zero edits elsewhere.
var svc = new PaymentService(new PayPal(), new SmsNotifier());
svc.ProcessTransaction(250m);

public interface IPaymentMethod { string Authorize(decimal amount); }
public interface INotifier      { void Send(string message); }

public class CreditCard : IPaymentMethod
{
    public string Authorize(decimal amount) => $"Charged ${amount} to credit card.";
}
public class PayPal : IPaymentMethod
{
    public string Authorize(decimal amount) => $"Charged ${amount} to PayPal.";
}
public class EmailNotifier : INotifier
{
    public void Send(string message) => Console.WriteLine($"EMAIL: {message}");
}
public class SmsNotifier : INotifier
{
    public void Send(string message) => Console.WriteLine($"SMS: {message}");
}

public class PaymentService
{
    private readonly IPaymentMethod _method;   // has-a
    private readonly INotifier _notifier;      // has-a

    public PaymentService(IPaymentMethod method, INotifier notifier)
        => (_method, _notifier) = (method, notifier);

    public void ProcessTransaction(decimal amount)
        => _notifier.Send(_method.Authorize(amount));   // delegation
}

SOLID — five principles, one goal

SOLID is a mnemonic for five design principles intended to make software designs more understandable, flexible and maintainable. They were popularised by Robert C. Martin; the L honours Barbara Liskov. You've already built the intuition for all five — the three principles above are their foundation.

S — Single Responsibility Principle

A class should have just one reason to change. Make every class responsible for a single part of the functionality, and make that responsibility entirely encapsulated by (hidden inside) the class. The main goal is reducing complexity — and containing change.

The slides' example: an Employee class that manages employee data and prints a timesheet report. Two reasons to change: (1) the core job — managing employee data — evolves; (2) the timesheet report format changes over time. Solution: move report printing into its own class. Your tutorial's bookstore invoice (Tutorial 19) is the same disease with three symptoms — data + math, formatting, and persistence in one "God class":

public class Invoice
{
    public string BookTitle { get; }
    public int Quantity { get; }
    public decimal Price { get; }

    public Invoice(string title, int qty, decimal price)
        => (BookTitle, Quantity, Price) = (title, qty, price);

    // Responsibility 1: business calculation
    public decimal GetTotal() => Price * Quantity;

    // Responsibility 2: presentation
    public void PrintInvoice()
        => Console.WriteLine($"Invoice: {BookTitle} x {Quantity} = ${GetTotal()}");

    // Responsibility 3: persistence
    public void SaveToFile(string path)
        => File.WriteAllText(path, $"{BookTitle}, total {GetTotal()}");
}

// Reason to change: billing rules
public class Invoice
{
    public string BookTitle { get; }
    public int Quantity { get; }
    public decimal Price { get; }

    public Invoice(string title, int qty, decimal price)
        => (BookTitle, Quantity, Price) = (title, qty, price);

    public decimal GetTotal() => Price * Quantity;
}

// Reason to change: how invoices are displayed
public class InvoicePrinter
{
    public void PrintToConsole(Invoice inv)
    {
        Console.WriteLine("--- INVOICE ---");
        Console.WriteLine($"Item:  {inv.BookTitle}");
        Console.WriteLine($"Total: ${inv.GetTotal()}");
    }
}

// Reason to change: where/how invoices are stored
public class InvoicePersistence
{
    public void SaveToFile(Invoice inv, string path)
        => File.WriteAllText(path, $"{inv.BookTitle}, total {inv.GetTotal()}");
}

O — Open/Closed Principle

Classes should be open for extension but closed for modification. The main idea: when you implement a new feature, don't break — or even touch — existing code. A class is open if you can extend it: subclass it, override behaviour, or plug new components into it. A class is closed (think "complete", like a shipped API) if it's ready to be used by others: its interface is stable. A class can be both at the same time — that's the goal.

The slides' scenario: an e-commerce Order class that calculates shipping cost with all shipping methods hard-coded inside. Adding a new shipping method means changing Order — and risking every order-related feature in the app:

public class Order
{
    public List<LineItem> Items { get; } = new();
    public string ShippingMethod { get; set; } = "ground";

    public decimal GetTotalWeight() => Items.Sum(i => i.Weight);

    public decimal GetShippingCost() => ShippingMethod switch
    {
        // Every new carrier = reopen this tested, shipped class
        "ground" => Math.Max(5m, GetTotalWeight() * 0.5m),
        "air"    => Math.Max(10m, GetTotalWeight() * 1.5m),
        _ => throw new ArgumentException("Unknown method")
    };
}

public interface IShipping
{
    string Name { get; }
    decimal GetCost(Order order);
}

public class GroundShipping : IShipping
{
    public string Name => "Ground";
    public decimal GetCost(Order o) => Math.Max(5m, o.GetTotalWeight() * 0.5m);
}

public class AirShipping : IShipping
{
    public string Name => "Air";
    public decimal GetCost(Order o) => Math.Max(10m, o.GetTotalWeight() * 1.5m);
}

// NEW FEATURE — a new file. No existing file was opened.
public class DroneShipping : IShipping
{
    public string Name => "Drone";
    public decimal GetCost(Order o) => 15m + o.GetTotalWeight() * 2m;
}

public class Order
{
    public List<LineItem> Items { get; } = new();
    public IShipping Shipping { get; }        // plug-in point — required, not an afterthought

    public Order(IShipping shipping) => Shipping = shipping;

    public decimal GetTotalWeight() => Items.Sum(i => i.Weight);
    public decimal GetShippingCost() => Shipping.GetCost(this);
}

L — Liskov Substitution Principle

When extending a class, you should be able to pass objects of the subclass anywhere the parent class is expected — without breaking the client code. Named for Barbara Liskov, who formalised it in 1987. In plain terms: the subclass must remain behaviour-compatible with the superclass. When you override a method, extend the base behaviour; don't replace it with something that surprises callers.

The one-sentence test

Whenever you create a subclass, ask:

The motivating crash: BankAccount vs FixedDepositAccount

From your tutorial (Tutorial 22): a bank has accounts with a Withdraw method. Then the bank introduces fixed deposits — accounts that don't allow withdrawal until maturity. The "obvious" model:

public class BankAccount
{
    public decimal Balance { get; protected set; }
    public BankAccount(decimal opening) => Balance = opening;

    public virtual void Withdraw(decimal amount)
    {
        Balance -= amount;
        Console.WriteLine($"Withdrew ${amount}. New balance: ${Balance}");
    }
}

public class SavingsAccount : BankAccount
{
    public SavingsAccount(decimal opening) : base(opening) { }
}

public class FixedDepositAccount : BankAccount
{
    public FixedDepositAccount(decimal opening) : base(opening) { }

    public override void Withdraw(decimal amount)
        // VIOLATION: the subclass "disables" an inherited operation
        => throw new InvalidOperationException(
               "Withdrawals are NOT allowed from fixed deposits!");
}

Now somebody — possibly in a different team, months later — writes perfectly reasonable client code against the base class:

public static void ProcessEndOfMonthFees(List<BankAccount> accounts)
{
    foreach (var acc in accounts)
        acc.Withdraw(100m);   // 💥 crashes the batch job the day
                              // a FixedDepositAccount enters the list
}

Nothing in ProcessEndOfMonthFees is wrong. Nothing in it ever changed. It still dies in production. That's the signature of an LSP violation: the crime and the crash are in different files.

The 7-point substitution checklist

The slides give a concrete checklist for "behaviour-compatible". A subclass method, compared with the base method it overrides, must satisfy all seven. The memory hook for the first two: inputs may loosen, outputs may tighten — never the reverse.

1. Parameter types: match or be more abstract (contravariance)

If the base method accepts a Cat, an override that effectively accepts any Animal is safe — it can handle everything clients already send, plus more. An override that only accepts BengalCat is dangerous — clients sending ordinary cats now fail.

class Trainer
{
    // Base promise: "give me any Cat"
    public virtual void Feed(Cat cat) => cat.Eat();
}

class PickyTrainer : Trainer
{
    // C# forces the override signature to match — but you can still
    // violate the RULE at runtime by rejecting inputs the base accepted:
    public override void Feed(Cat cat)
    {
        if (cat is not BengalCat)                       // ❌ demands MORE
            throw new ArgumentException("Bengals only!");
        cat.Eat();
    }
}

2. Return type: match or be a subtype (covariance)

Requirements for return types are the inverse of parameter types. The client says Cat c = shelter.BuyCat(); — anything that is a cat keeps that line working:

class CatShelter
{
    public virtual Cat BuyCat() => new Cat();
}

class BengalShelter : CatShelter
{
    // ✅ Legal since C# 9: covariant return. A BengalCat IS a Cat,
    // so every existing caller still gets what it was promised.
    public override BengalCat BuyCat() => new BengalCat();
}

// ❌ Returning something MORE GENERAL (e.g. plain object / an Animal
// that may not be a Cat) would break callers expecting Cat members.

3. No new exception types

Exceptions thrown by the override should match, or be subtypes of, the ones the base method already throws — because try/catch blocks in client code target the base method's documented exceptions. A brand-new exception type slips past every existing catch and crashes the application:

class BankAccount
{
    // Documented contract: throws InsufficientFundsException only
    public virtual void Withdraw(decimal amount)
    {
        if (amount > Balance) throw new InsufficientFundsException();
        Balance -= amount;
    }
}

class FixedDepositAccount : BankAccount
{
    public override void Withdraw(decimal amount)
        => throw new DepositLockedException();   // ❌ new type — client's
                                                 // catch (InsufficientFundsException)
                                                 // never sees it coming
}

4. Don't strengthen pre-conditions

A pre-condition is what must be true before a method is called (jargon: the method's demands on its caller). The base method sets the bar; a subclass may lower it, never raise it. Slide example: the base accepts any int; the override throws on negatives. Client code that happily passed negative numbers for years now breaks — but only when it happens to receive the subclass:

class SavingsAccount : BankAccount
{
    // Base precondition: 0 < amount ≤ Balance
    public override void Withdraw(decimal amount) { /* same as base */ }
}

class PremiumAccount : BankAccount
{
    public override void Withdraw(decimal amount)
    {
        if (amount < 100m)                        // ❌ STRONGER demand:
            throw new ArgumentException(          // base allowed $20,
                "Minimum withdrawal is $100.");   // this rejects it
        Balance -= amount;
    }
}

5. Don't weaken post-conditions

A post-condition is what the method guarantees is true after it returns (its promises). A subclass may promise more, never less. Slide example: a base method that works with a database always closes its connections before returning. A subclass keeps connections open "for reuse". The client, trusting the base promise, terminates right after the call — and litters the system with ghost connections:

class ReportJob
{
    public virtual void Run()
    {
        var conn = OpenConnection();
        try { /* ... write report ... */ }
        finally { conn.Close(); }          // promise: nothing left open
    }
}

class PooledReportJob : ReportJob
{
    public override void Run()
    {
        var conn = OpenConnection();
        /* ... write report ... */
        // ❌ keeps conn open for "efficiency" — a WEAKER guarantee.
        // Clients that exit immediately afterwards leak connections.
    }
}

6. Preserve the superclass's invariants

An invariant is a condition that must hold for the object's entire lifetime — often unwritten: "a cat has four legs", "Balance never goes negative", "changing a rectangle's width doesn't touch its height". Invariants are the sneakiest rule because many live only in the original author's head. The safest override adds behaviour without touching existing state. The classic violation is Rectangle/Square — expanded in the deep-dive below.

7. Don't change state the base class wouldn't allow

Closely related to invariants: a subclass shouldn't mutate the superclass's private/internal state in ways the base's own methods never would. Some languages let you do it anyway — reflection in C#/Java, or Python and JavaScript where "private" is a naming convention with no enforcement. The fact that you can reach the field doesn't make the resulting object substitutable:

class SavingsAccount
{
    protected decimal _balance;               // base's own methods
    public decimal Balance => _balance;       // NEVER let it go below 0
    public virtual void Withdraw(decimal a)
    {
        if (a > _balance) throw new InsufficientFundsException();
        _balance -= a;
    }
}

class OverdraftAccount : SavingsAccount
{
    public override void Withdraw(decimal a)
        => _balance -= a;    // ❌ can drive _balance negative — a state
                             // no base-class method could ever produce.
                             // Every client assuming Balance ≥ 0 breaks.
}

Two fast smell tests (from your tutorial)

Worked example A — the read-only document (slides, checklist rule 7)

The slides close the checklist with this scenario: a document hierarchy where ReadOnlyDocument subtracts an ability instead of adding one.

public class Document
{
    public string Data { get; set; } = "";
    public virtual void Open() => Console.WriteLine("Opening...");
    public virtual void Save() => Console.WriteLine("Saving...");
}

public class ReadOnlyDocument : Document
{
    public override void Save()
        => throw new NotSupportedException("Can't save a read-only file.");
}

public class Project
{
    public List<Document> Documents { get; } = new();

    public void SaveAll()
    {
        foreach (var doc in Documents)
            if (doc is not ReadOnlyDocument)   // client forced to type-check!
                doc.Save();
    }
}

// The BASE class promises only what EVERY document can do
public class Document
{
    public string Data { get; protected set; } = "";
    public void Open() => Console.WriteLine("Opening...");
}

// The subclass EXTENDS behaviour by adding the save ability
public class WritableDocument : Document
{
    public void Save() => Console.WriteLine("Saving...");
}

public class Project
{
    public List<Document> AllDocs { get; } = new();
    public List<WritableDocument> WritableDocs { get; } = new();

    public void SaveAll()
    {
        foreach (var doc in WritableDocs)   // no type checks —
            doc.Save();                     // everything here CAN save
    }
}

Worked example B — fixing the bank hierarchy

Apply the same move to the fixed-deposit crash from earlier. FixedDepositAccount can't honour the Withdraw contract, so it must not inherit it. Split the hierarchy by capability:

public abstract class Account
{
    public decimal Balance { get; protected set; }
    protected Account(decimal opening) => Balance = opening;
    public void Deposit(decimal amount) => Balance += amount;
}

public abstract class WithdrawableAccount : Account
{
    protected WithdrawableAccount(decimal opening) : base(opening) { }
    public abstract void Withdraw(decimal amount);
}

public class SavingsAccount : WithdrawableAccount
{
    public SavingsAccount(decimal opening) : base(opening) { }
    public override void Withdraw(decimal amount)
    {
        if (amount > Balance) throw new InsufficientFundsException();
        Balance -= amount;
    }
}

public class FixedDepositAccount : Account      // note: NOT withdrawable
{
    public FixedDepositAccount(decimal opening) : base(opening) { }
    public void AddInterest() => Balance *= 1.05m;
}

// The batch job now DECLARES what it needs — the compiler enforces LSP:
public static void ProcessEndOfMonthFees(List<WithdrawableAccount> accounts)
{
    foreach (var acc in accounts)
        acc.Withdraw(100m);      // cannot crash: fixed deposits can't
}                                // even enter this list

The crash didn't just get handled — it became unwritable. Passing a fixed deposit to the batch job is now a compile-time error instead of a 2 a.m. production incident. (Here an abstract class is the right abstraction rather than an interface, because accounts share state — Balance — and shared logic like Deposit.)

public class Rectangle
{
    public virtual int Width  { get; set; }
    public virtual int Height { get; set; }
    public int Area => Width * Height;
}

public class Square : Rectangle
{
    public override int Width
    {
        get => base.Width;
        set { base.Width = value; base.Height = value; }  // keep it square
    }
    public override int Height
    {
        get => base.Height;
        set { base.Height = value; base.Width = value; }
    }
}

static void StretchToTwenty(Rectangle r)
{
    r.Width = 4;
    r.Height = 5;
    // Every Rectangle ever: area is 20.
    Console.WriteLine(r.Area);   // Rectangle → 20   Square → 25 💥
}

I — Interface Segregation Principle

Clients shouldn't be forced to depend on methods they don't use. Make interfaces narrow enough that implementing classes never have to write "dummy" methods for behaviour they don't have. There's no need to cram unrelated methods into one interface — break it into several refined ones. A class can implement as many interfaces as it likes (unlike class inheritance, which in C# allows only one base class), so small interfaces cost nothing to recombine.

Your tutorial's scenario (Tutorial 23): office equipment. High-end machines print, scan and fax, so the first design starts with one "multi-function device" interface. Then a humble home printer shows up:

public interface IMultiFunctionDevice
{
    void PrintDocument(string doc);
    void ScanDocument(string doc);
    void FaxDocument(string doc);
}

public class OfficeSuperPrinter : IMultiFunctionDevice
{
    public void PrintDocument(string doc) => Console.WriteLine("Printing...");
    public void ScanDocument(string doc)  => Console.WriteLine("Scanning...");
    public void FaxDocument(string doc)   => Console.WriteLine("Faxing...");
}

public class SimpleHomePrinter : IMultiFunctionDevice
{
    public void PrintDocument(string doc) => Console.WriteLine("Printing at home...");

    // Forced to "implement" hardware it doesn't have:
    public void ScanDocument(string doc)
        => throw new NotSupportedException("No scanner installed.");
    public void FaxDocument(string doc)
        => throw new NotSupportedException("It's 2026. No fax.");
}

public interface IPrinter { void PrintDocument(string doc); }
public interface IScanner { void ScanDocument(string doc); }
public interface IFax     { void FaxDocument(string doc); }

public class SimpleHomePrinter : IPrinter
{
    public void PrintDocument(string doc) => Console.WriteLine("Printing at home...");
}

public class Photocopier : IPrinter, IScanner
{
    public void PrintDocument(string doc) => Console.WriteLine("Copy-printing...");
    public void ScanDocument(string doc)  => Console.WriteLine("Copy-scanning...");
}

public class OfficeSuperPrinter : IPrinter, IScanner, IFax
{
    public void PrintDocument(string doc) => Console.WriteLine("Printing...");
    public void ScanDocument(string doc)  => Console.WriteLine("Scanning...");
    public void FaxDocument(string doc)   => Console.WriteLine("Faxing...");
}

// The CLIENT declares exactly what it needs — nothing more:
public static void ArchiveContract(IScanner scanner)
    => scanner.ScanDocument("Contract.pdf");

// ArchiveContract(new SimpleHomePrinter());  ← compile error.
// The impossible operation became impossible to request.

D — Dependency Inversion Principle

The final piece of the puzzle. Two statements, straight from the slides:

1. High-level modules shouldn't depend on low-level modules. Both should depend on abstractions.
2. Abstractions shouldn't depend on details. Details should depend on abstractions.

Jargon first. Low-level classes implement basic operations: talking to a disk, transferring data over a network, connecting to a database. High-level classes contain the business logic that directs low-level classes to do something — the code that embodies what your application is actually for. An abstraction here means an interface or abstract class describing an operation in business terms ("get me a temperature", "notify the customer") rather than implementation terms ("run this SQL").

Your tutorial's weather reporter (Tutorial 25) shows both directions of the arrow:

public class LocalDatabase
{
    public double GetTemperature() => 22.0;   // low-level detail
}
public class EmailService
{
    public void Send(string msg) => Console.WriteLine($"EMAIL: {msg}");
}

public class WeatherReporter
{
    // Hard-coded dependencies, created INSIDE the class
    private readonly LocalDatabase _source  = new();
    private readonly EmailService  _notifier = new();

    public void Report()
    {
        double t = _source.GetTemperature();
        _notifier.Send($"Current temperature is {t}°C");
    }
}

// Wiring — the ONLY place that knows concrete types:
var reporter = new WeatherReporter(new CloudWeatherApi(), new SmsService());
reporter.Report();

// Abstractions — defined in terms of what the HIGH level needs
public interface IWeatherSource { double GetTemperature(); }
public interface INotifier      { void Send(string message); }

// Details now depend on (implement) the abstractions
public class LocalDatabase : IWeatherSource
{
    public double GetTemperature() => 22.0;
}
public class CloudWeatherApi : IWeatherSource
{
    public double GetTemperature() => 28.0;   // satellite feed
}
public class EmailService : INotifier
{
    public void Send(string msg) => Console.WriteLine($"EMAIL: {msg}");
}
public class SmsService : INotifier
{
    public void Send(string msg) => Console.WriteLine($"SMS: {msg}");
}

public class WeatherReporter
{
    private readonly IWeatherSource _source;
    private readonly INotifier _notifier;

    // DEPENDENCY INJECTION: the tools are handed in from outside
    public WeatherReporter(IWeatherSource source, INotifier notifier)
        => (_source, _notifier) = (source, notifier);

    public void Report()
        => _notifier.Send($"Current temperature is {_source.GetTemperature()}°C");
}

All five, one story

Run the TravelAlert capstone from your tutorial through the whole alphabet: the AlertCoordinator only coordinates (S); adding SlackService touches no existing file (O); every IMessageService honours Send so the coordinator's loop never breaks (L); read-receipt tracking sits in a separate ITrackable so SMS isn't forced to fake it (I); and the coordinator sees only IDataSource/IMessageService/ILogger (D). Five principles, but really one instinct applied five ways: protect what's stable from what changes, through small, honest contracts.

From principles to patterns

You've now watched the same thing happen twice: following "encapsulate what varies" produced Strategy, and following "program to an interface" produced Factory Method. That's not a coincidence — it's the whole idea. A design pattern is a general, reusable solution to a commonly occurring problem in software design.

Three clarifications the slides insist on, because each kills a common misconception:

• A pattern is not a finished design you can transform directly into code. It's a description or template for how to solve a problem, usable in many different situations. There is no Strategy.cs to download; there's a shape you re-create in your own domain.
• Patterns deal with problems at the level of software design — how classes and objects relate. Not every software pattern is a design pattern (there are also architectural patterns, chapter 8, and idioms at the code level, chapter 7).
• Algorithms are not design patterns. Quicksort solves a computational problem (given input, produce output efficiently). Patterns solve design problems (how do I add carriers without editing Order?). An algorithm is a recipe; a pattern is a floor plan.

The design challenge patterns answer

Recall the tension from the top of this page. A design should be specific to the problem at hand, yet general enough to address future problems and requirements — and you want to avoid redesign, or at least minimise it. How do expert designers manage that balancing act? The slides' answer is disarmingly honest: they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Patterns are simply that expert experience, written down, named, and organised — so you don't need ten years of scar tissue to design like someone who has it.

The four essential elements of a pattern

Every properly documented pattern (in the Gang of Four catalogue and in chapters 3–5 of this site) has four parts:

Two axes of classification

By purpose — what kind of design problem the pattern attacks. This gives the three families that structure chapters 3–5:

By scope — the axis everyone skips, so let's not. Scope specifies whether the pattern applies primarily to classes or to objects:

Almost all patterns use inheritance somewhere (usually to define interfaces/abstract classes), so the "class pattern" label is reserved for the few whose core mechanism is a class relationship. Crossing the two axes, the slides note how each purpose splits by scope:

Patterns relate to each other

The GoF book ends with a famous "pattern relationships" map, and you'll feel it constantly in chapters 3–5: patterns chain (a principle's fix becomes a pattern's starting point — encapsulate-what-varies grows into Strategy), collaborate (a Composite is often built by a Builder, traversed by an Iterator, operated on by a Visitor), and rhyme (Strategy, State and Command have near-identical UML but totally different intents — which is why chapter 12 exists to compare the confusable ones side by side). Learn each pattern's intent, not its class diagram; diagrams repeat, intents don't. Chapter 6 then shows many patterns cooperating inside one document-editor case study.

End-of-chapter quiz

Eight scenarios. For each, identify the principle (or concept) at play — the skill the exam, and real code reviews, actually test.

Solid on all of it? (Pun fully intended.) Then you're ready for the catalogue: Chapter 3 — Creational Patterns. If any principle still feels wobbly, the fastest fix is to revisit its interactive demo above and predict each log line before clicking.