Foundations Studio

Classes: FitnessCentre, Room, Equipment, Trainer, Member, ClassSession, Booking (the member-session link carries data — who, when — so it earns classhood), and a billing service. Rejected nouns: credit balance → a decimal attribute of Member (state, no independent behaviour or identity); receipt → the message a notifier sends, not a stored entity (in this scope); capacity → an int invariant on ClassSession. The abstraction: fee plan. Standard, Premium and the announced Student plan are three behaviours behind one contract — model it as an IFeePlan interface now, because the brief tells you a new variant is coming. Remember chapter 1's airplane lesson: an abstraction keeps only what this program needs — no HeartRate on Member.

public decimal Credits { get; private set; }   // read anywhere, written only in here

public void AddCredits(decimal amount)   // guard: amount > 0
public void Charge(decimal amount)       // guards: amount > 0  AND  amount <= Credits

Credits is readable (the UI needs it) but only settable internally — so the invariant "credits ≥ 0" is enforced in exactly two places instead of trusted to every caller forever. The guard on Charge rejecting non-positive amounts matters as much as the sufficiency check: without it, Charge(-100) would increase the balance — the precise bug encapsulation exists to prevent.

Failure 1 — identity is frozen: membership tier is a state that changes (upgrades, downgrades, student graduates), but an object's class is fixed at construction. Upgrading means destroying the member and rebuilding it — losing object identity, bookings, and history. Failure 2 — combinatorial explosion: add one more axis (corporate billing, family add-on) and you need CorporateStudentMember, FamilyPremiumMember… the explosion chapter 2 warns about. Alternative: one concrete Member that has a IFeePlan — composition. Swapping the plan object at runtime is an upgrade. Inheritance is the right tool when the subtype differs in what it is permanently; here the variation is in how the fee is computed, a behaviour — behaviour varies → compose.

• Centre —◆ Room: composition. Rooms are created by the centre and scrapped when it closes — the part's lifetime is bounded by the whole's.
• Room —◆ Equipment: composition. Bolted down, asset-tagged, scrapped with the building. Part-of-a-part.
• Centre —◇ Trainer: aggregation. Trainers freelance across centres and survive a closure — shared, independent lifetime; the centre merely holds references.
• Member — ClassSession: association, many-to-many, reified as a Booking link class because the link carries data. Both ends outlive any single booking.
• ClassSession —◇ Trainer: aggregation. The session has a coach it doesn't own; cancel the session and Ravi still exists.
• BillingService ⤳ INotifier: held abstraction (aggregation of an interface). The service stores an injected INotifier it does not create or own. (If it only received the notifier per-call and never stored it, that would weaken to dependency — the distinction chapter 1 draws for Doctor/Patient.)

public class Room
{
    public bool IsOpen { get; private set; } = true;

    internal Room(string name) => Name = name;   // ← assembly-only creation: a composition convention

    internal void Decommission()                 // ← called only by the owner
    {
        IsOpen = false;
        _equipment.Clear();
    }
}

public class FitnessCentre
{
    public Room OpenRoom(string name)
    {
        var r = new Room(name);   // part created INSIDE the whole
        _rooms.Add(r);
        return r;
    }
    public void Close()
    {
        foreach (var room in _rooms)
            room.Decommission();  // logical invalidation: retained references become unusable
        _rooms.Clear();
    }
}

Notice: the relationship isn't a comment — it's the code shape, and be precise about what that shape buys you. The internal constructor restricts construction to the assembly: a convention that approximates "only the owner creates its parts", not something the compiler can literally enforce — any type in the assembly could call it. And in a garbage-collected language you cannot destroy an object, so composition's "part dies with the whole" is a modeling claim the code makes observable through logical invalidation: Close() decommissions each room, so even a caller who kept the reference from OpenRoom finds it IsOpen == false and unusable. Aggregation reads opposite: HireTrainer(Trainer trainer) accepts an object that already exists and leaves it untouched on Close(). The test file checks these shapes with reflection and a retained-reference lifetime test, exactly the discipline an examiner checks in your diagram.

Both are whole–part ("has-a") relationships; they differ in lifetime ownership. Composition: the whole owns the part's lifecycle — a Room is created inside FitnessCentre.OpenRoom() and logically decommissioned by Close() (the CLR object may remain reachable, but it reports IsOpen == false and refuses further use); the part has no independent role in the model. UML: filled diamond at the centre's end. C#: the part is instantiated inside the owner, its constructor hidden (internal Room(...)) — an assembly-level convention that keeps creation with the owner. Aggregation: the whole holds a reference to a part that lives independently — a Trainer is constructed elsewhere, passed into HireTrainer(), and survives the centre closing. UML: open diamond. C#: a public-constructor object received as a parameter and stored. The test is always destruction: delete the whole — does the part die?

Three reasons to change: (1) fee rules change (pricing/marketing decides a new plan or rate); (2) notification channel changes (ops wants SMS or push instead of email); (3) the charging workflow itself changes (finance wants proration). Extraction: fee computation → the IFeePlan implementations; message delivery → an INotifier implementation; orchestration → BillingService, whose only job is "ask the plan for the fee, hand the message to the notifier". Compare the bookstore Invoice split (data / printer / persistence) from the tutorials — same move, different domain.

public interface IFeePlan
{
    string Name { get; }
    decimal MonthlyFee(int visits);
}

public sealed class StudentPlan : IFeePlan
{
    public string Name => "Student";
    public decimal MonthlyFee(int visits)
        => Math.Min(20m + 2m * Math.Max(0, visits), 40m);
}

This is the Strategy shape (formalised in chapter 5). Closed for modification: BillingService and the existing plan classes — nobody opens those files again. Open for extension: the IFeePlan contract — a new plan is a new file implementing it. The cinema-ticket tutorial made the same move: the calculator stays two lines long no matter how many discounts exist.

A is fine. Zero is a legitimate fee: every caller that sums, compares, or formats fees keeps working. Weird business-wise, sound contract-wise. B violates LSP — it disables the parent contract with an exception, exactly the checklist's first red flag. Runtime consequence: MonthlyRevenue() iterates all subscriptions polymorphically; one corporate member in the list crashes the entire month-end run — code that was correct for every other plan breaks without being touched. Redesign: corporate members shouldn't be behind IFeePlan at all. Model invoiced billing as a separate contract (e.g. IInvoicedAccount) and keep the monthly-fee pipeline for types that can honour it — the same interface-split cure as the withdrawable/fixed-deposit refactor.

A fat interface forces rowers and lockers to stub methods they can't honour — and a stub is either a no-op lie or a thrown exception, which is yesterday's LSP violation manufactured wholesale. Segregate by capability: IPowered (on/off), IUsageReporting, IHeartRateSource, IInclinable. Treadmill implements all four; rower skips IInclinable; locker implements just IPowered + IUsageReporting. Client code then asks only for the capability it needs — a maintenance job that powers devices down takes IEnumerable<IPowered> and cannot even receive a device it might misuse. (Same cure as the tutorials' printer/scanner/fax split.)

DIP: the high-level policy (billing) must not depend on the low-level detail (email); both depend on an abstraction — and crucially, the abstraction belongs to the high-level side. INotifier.Send(memberId, message) is billing's vocabulary; EmailSender adapts itself to it, not the other way round. That's the inversion: the detail now depends on the policy's contract. Mechanically: inject INotifier through the constructor and delete the new. Testing benefit: substitute a spy notifier and assert "charging sent exactly one message to M-1" with no mail server — which is literally what lab F02's tests do.

public decimal ChargeMonthly(string memberId, IFeePlan plan, int visits)
{
    var fee = plan.MonthlyFee(visits);                       // strategy does the varying part
    _notifier.Send(memberId, $"Your {plan.Name} membership fee this month is {fee:0.00}.");
    return fee;
}

Notice: after the refactor, BillingService contains no plan names, no if, no new. Everything that varies arrived through a contract. When the Step-4 test passes — StudentPlan summed correctly by a service that has never heard of it — you have witnessed OCP as a runtime fact.

MonthlyRevenue() depends only on the IFeePlan abstraction: it iterates subscriptions and calls plan.MonthlyFee(visits) polymorphically. A new plan is a new implementing class; the service binds to it at runtime without recompilation of existing code — open for extension, closed for modification. But OCP's promise silently assumes substitutability: the service treats all plans identically because it may. If one implementation throws or returns garbage (Step 3's CorporatePlan), the unmodified, "closed" MonthlyRevenue() now fails — the extension broke the closed code. LSP is therefore not a separate nicety: it is the precondition that makes OCP's polymorphic extension point safe. Strategy provides the mechanism; Liskov provides the warranty.

public abstract class Account
{
    public decimal Balance { get; protected set; }
}

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

public sealed class SavingsAccount : WithdrawableAccount
{
    public override void Withdraw(decimal amount)
    {
        if (amount <= 0 || amount > Balance) throw new InvalidOperationException();
        Balance -= amount;
    }
}

public sealed class FixedDepositAccount : Account   // no Withdraw to betray
{
    public void AddInterest() => Balance *= 1.05m;
}

void ProcessWithdrawals(IEnumerable<WithdrawableAccount> accounts) { /* type-safe */ }

Fails the No-Op/Exception test. The fix moves Withdraw down into a contract only capable types implement — ProcessWithdrawals now cannot even receive a fixed deposit. Note the guard inside Withdraw: same encapsulation reflex as FitCore Step 2.

public interface IDiscountPolicy { decimal Apply(decimal subtotal); }

public sealed class FixedDiscount : IDiscountPolicy
{
    private readonly decimal _off;
    public FixedDiscount(decimal off) => _off = off;
    public decimal Apply(decimal subtotal) => Math.Max(0m, subtotal - _off);
}

var order = new PizzaOrder(new UkTax(), new WoodFireOven(), new FixedDiscount(5.00m));

PizzaOrder.Total() just calls _discount.Apply(...) in its pipeline. A new promotion is a new class — the order class is closed. Note Math.Max(0m, ...): the policy keeps its own contract LSP-clean (never a negative total).

public interface IWeatherSource { double GetTemperature(); }
public interface INotifier      { void Send(string message); }

public sealed class WeatherReporter
{
    private readonly IWeatherSource _source;
    private readonly INotifier _notifier;
    public WeatherReporter(IWeatherSource source, INotifier notifier)
        { _source = source; _notifier = notifier; }

    public void Report()
        => _notifier.Send($"Weather Update: {_source.GetTemperature()} degrees.");
}

var reporter = new WeatherReporter(new CloudApi(), new SmsService());   // the swap

Both abstractions are written in the reporter's vocabulary (a temperature, a message) — the high-level module owns the contracts and the details adapt. This is the exact shape FitCore's BillingService(INotifier) uses in lab F02.

public interface ICamera { string Capture(); }

public sealed class SelfieCamera : ICamera
{
    public string Capture() => "Front lens: image flipped and captured.";
}

public sealed class MockCamera : ICamera
{
    public string Capture() => "TEST-CAPTURE";
}

public sealed class CameraApp
{
    private ICamera _camera;
    public CameraApp(ICamera camera) => _camera = camera;      // injected, not newed
    public void SetCamera(ICamera camera) => _camera = camera;  // runtime swap
    public string PressShutter() => _camera.Capture();
}

The mock is trivial because the app's only requirement is the one-method contract — no hardware, no setup, one line. That "ease of faking" is the everyday payoff of loose coupling, and it's how every lab in this studio tests your code.

public interface ISwitchable { void TurnOn(); void TurnOff(); }

public sealed class Fan : ISwitchable
{
    public void TurnOn()  => Console.WriteLine("Fan is spinning");
    public void TurnOff() => Console.WriteLine("Fan stopped");
}

public sealed class Switch
{
    private readonly ISwitchable _device;
    private bool _isOn;
    public Switch(ISwitchable device) => _device = device;

    public void Toggle()
    {
        if (_isOn) _device.TurnOff(); else _device.TurnOn();
        _isOn = !_isOn;
    }
}

Aggregation. The device is created outside, passed in, merely referenced — discard the switch and the fan still exists. High-level Switch no longer depends on any concrete device; both depend on ISwitchable — DIP in five lines.

An abstract PropulsionSystem (Accelerate(double), GetStatus()) is the contract — abstraction. ElectricMotor keeps _voltage private behind a validated SetVoltage that throws on negatives and on > 800 V — encapsulation (NFR-1.1/1.2). DriverInput stores a PropulsionSystem reference and calls Accelerate, so electric and hydrogen respond each in their own way — polymorphism; and because it references only the abstraction, CONST-1.1 is satisfied by construction, which is DIP avant la lettre. Then Build: make the two Stage1_ tests pass — voltage rejection and one DriverInput driving both engines.

Split by capability: IVisualSensor { GetVideoFeed() } and IDistanceSensor { GetDistanceMeters() }. Camera4K : IVisualSensor; Sonar : IDistanceSensor only — it is never forced to fake video; Lidar : IDistanceSensor, IVisualSensor — multiple small interfaces compose where one fat one would lie. Constructor injection satisfies CONST-2.1: Autopilot(IEnumerable<IVisualSensor>, IEnumerable<IDistanceSensor>) — the car is assembled by a bootstrapper outside, so a camera-only city car and a lidar+sonar truck both boot the same Autopilot code. Then Build: the two Stage2_ tests — any-combination braking logic, and a reflection check that Sonar is not an IVisualSensor.

IDrivingStrategy { ApplyThrottle(); ApplyBrakes(); } with SportMode, EcoMode, OffroadMode. CarController has a strategy and delegates — SetMode(IDrivingStrategy) swaps it live, and Drive() contains zero conditionals. The knockout: an object's class is fixed at construction, so a running SportCar can never become an EcoCar — only a composed reference can be reassigned mid-drive. (Composition over inheritance, now with an SRS constraint enforcing it.) Then Build: Stage3_ — a live Sport→Eco swap observed through Drive().

Stage 3 already built the extension point: CarController depends only on IDrivingStrategy, so ValetMode : IDrivingStrategy is a pure addition — NFR-4.1 is OCP (extend by adding a class, never by editing). It works only because ValetMode genuinely honours the contract — throttle and brakes both respond, just restrictively — so substituting it for SportMode cannot crash the controller: NFR-4.2 is LSP. A ValetMode that threw from ApplyThrottle() would be Stage-3's CorporatePlan all over again. Then Build: Stage4_ — the test hands ValetMode to the untouched controller and drives.