Five letters, one goal: code that can be changed safely, over and over, for years.

Picture a class called OrderManager. Eighteen months ago it validated an order and saved it to the database. Today it also calculates tax, applies discounts, sends confirmation emails, logs to a file, and — added last sprint — talks to a shipping API. Nobody planned this. Each change was small and reasonable on its own. But now the class is 900 lines long, three different teams touch it for three unrelated reasons, and every deploy carries a faint dread: what did I just break?

This is not a rare, unlucky codebase. It is the default outcome of software that changes over time without deliberate structural discipline. SOLID is a set of five design principles — named with the acronym S-O-L-I-D — that exist specifically to fight this decay. They were assembled by Robert C. Martin from ideas developed across the object-oriented design community (Bertrand Meyer's work on Open/Closed, Barbara Liskov's substitution rule among them), and they've held up for decades because they target the one thing every real system has in common: it will change, and the question is only whether changing it stays safe.

Two of the five — Interface Segregation and Dependency Inversion — already got full, dedicated lessons back in Lessons 079 and 081. This lesson brings all five together for the first time, goes deep on the three that haven't had their own lesson yet — Single Responsibility, Open/Closed, and Liskov Substitution — and, most importantly, shows you why all five are really the same idea wearing five different outfits.

In this lesson, you'll learn what each SOLID principle actually says (precisely, not the watered-down version), see a genuine before/after for S, O, and L with real code, briefly recap I and D in their proper place, and understand why "SOLID" is best understood as a single, unified answer to a single question: how do you build software that stays easy to change?

What Is It?

The Simple Explanation

SOLID is five rules of thumb for shaping classes and their relationships so that adding a feature, fixing a bug, or swapping an implementation doesn't force you to rewrite — or risk breaking — code that already works. Each letter names one rule:

The Technical Definition

Single Responsibility Principle (SRP): a class or module should have only one reason to change. Not "one method," not "does one tiny thing" — one reason, meaning one axis of change, one stakeholder or business concern whose requirements would drive an edit to this code.

Open/Closed Principle (OCP): software entities (classes, modules, functions) should be open for extension but closed for modification. You should be able to add new behavior without editing, recompiling, and re-testing code that already works and is already deployed.

Liskov Substitution Principle (LSP): if S is a subtype of T, objects of type T in a program should be replaceable with objects of type S without altering the correctness of that program. A subtype must honor the behavioral contract of its base type, not merely match its method signatures.

Interface Segregation Principle (ISP) and Dependency Inversion Principle (DIP) already have their own full lessons — Lesson 079 and Lesson 081 — so this lesson won't re-teach them from scratch. Quick recap of each, for completeness:

• ISP (recap): a "fat" interface with ten members forces every consumer to depend on all ten, even ones it never calls. Split large interfaces into small, focused ones so a class only depends on what it actually uses. See Lesson 079 for the full treatment.
• DIP (recap): high-level policy code (like OrderService) should depend on abstractions (IPaymentGateway) rather than concrete, low-level implementations (StripeGateway) — and those abstractions should be owned by the high-level side, not the low-level side. See Lesson 081 for the full treatment, including how DIP differs from Dependency Injection.

Why Does It Exist?

The Problem — Software Rots Under Its Own Changes

Every real system evolves. New requirements arrive; old ones change shape; the business finds a new way to make money that nobody designed for. Code that isn't deliberately structured to absorb change accumulates what practitioners call rigidity (one change forces ten more), fragility (a change in one place breaks something unrelated), and immobility (you can't reuse a piece because it's tangled into everything around it). None of that shows up on day one. It shows up eighteen months in, exactly like the OrderManager in the hook.

The Solution — Five Targeted Countermeasures

Each SOLID principle is a countermeasure aimed at one specific failure mode:

• SRP stops one class from becoming the collision point for unrelated changes — so a tax-rule change can't accidentally break email sending.
• OCP stops "adding a feature" from meaning "editing code that already shipped and already works" — so new behavior can't destabilize old behavior.
• LSP stops polymorphism from lying to you — so code written against a base type keeps working correctly no matter which subtype actually shows up at runtime.
• ISP stops interfaces from coupling classes to methods they never call — so a change to an unused method can't ripple into unrelated consumers.
• DIP stops high-level policy from being welded to low-level detail — so swapping a database or a payment provider doesn't require rewriting business logic.

Five different symptoms; one underlying disease. Keep that in mind — it's where this lesson ends up.

Big Picture

How It Works — Single Responsibility Principle

The most common misreading of SRP is "a class should do one thing" — taken so literally that people start splitting classes down to a single method out of guilt. That's not the principle. The actual definition is about reasons to change, also called axes of change or stakeholders. A class that calculates payroll, formats a payslip PDF, and emails it has three reasons to change: payroll rules change (finance), the PDF layout changes (design), the email provider changes (infrastructure). Three unrelated teams can each force an edit to the same class — and each one risks breaking the other two concerns by accident.

Before — One Class, Three Reasons to Change

public class PayslipService
{
    public decimal CalculateNetPay(Employee employee)
    {
        // Reason to change #1: finance changes tax bands, deduction rules...
        var gross = employee.BaseSalary + employee.Bonus;
        var tax = gross * 0.22m;
        return gross - tax;
    }

    public string FormatPayslip(Employee employee, decimal netPay)
    {
        // Reason to change #2: design wants a new payslip layout...
        return $"Payslip for {employee.Name}\nNet Pay: {netPay:C}\n---";
    }

    public void EmailPayslip(Employee employee, string payslipText)
    {
        // Reason to change #3: infrastructure switches email providers...
        var smtp = new System.Net.Mail.SmtpClient("smtp.internal.local");
        smtp.Send("payroll@company.com", employee.Email, "Your Payslip", payslipText);
    }
}

Every one of these three concerns can change independently, for unrelated reasons, on unrelated schedules — yet they all live in one class, sharing one set of fields, one set of tests, one blast radius.

After — Split Along Genuine Reasons to Change

public class PayrollCalculator
{
    // Only changes when finance changes pay rules.
    public decimal CalculateNetPay(Employee employee)
    {
        var gross = employee.BaseSalary + employee.Bonus;
        var tax = gross * 0.22m;
        return gross - tax;
    }
}

public class PayslipFormatter
{
    // Only changes when the payslip layout changes.
    public string Format(Employee employee, decimal netPay) =>
        $"Payslip for {employee.Name}\nNet Pay: {netPay:C}\n---";
}

public class PayslipMailer(ISmtpClient smtp)
{
    // Only changes when the email/delivery mechanism changes.
    public void Send(Employee employee, string payslipText) =>
        smtp.Send("payroll@company.com", employee.Email, "Your Payslip", payslipText);
}

// A thin orchestrator wires the pieces together — but owns none of their logic.
public class PayslipWorkflow(PayrollCalculator calculator, PayslipFormatter formatter, PayslipMailer mailer)
{
    public void RunFor(Employee employee)
    {
        var netPay = calculator.CalculateNetPay(employee);
        var text = formatter.Format(employee, netPay);
        mailer.Send(employee, text);
    }
}

Now a change to tax rules touches only PayrollCalculator. A change to layout touches only PayslipFormatter. Nobody testing the tax logic needs to know an SMTP server exists. Each class answers to exactly one stakeholder — that's SRP, correctly applied.

How It Works — Open/Closed Principle

"Open for extension, closed for modification" sounds paradoxical until you see it in code. It means: when a new case shows up, you should be able to add something — a new class, a new implementation — rather than edit something that already works, is already tested, and is already running in production.

Before — A Switch Statement That Must Grow Forever

public class DiscountCalculator
{
    public decimal Apply(string customerType, decimal total) => customerType switch
    {
        "Regular" => total,
        "Vip" => total * 0.90m,
        "Employee" => total * 0.80m,
        _ => total
    };
}

This works — until the business adds a "Seasonal" discount, or a "FirstTimeBuyer" discount, or a "Loyalty" tier with rules that depend on order history. Every single new discount type means opening this file, editing a method that every existing discount type already relies on, and re-testing all of them to make sure the edit didn't break anything. The blast radius of "add one new discount" is "the entire discount system."

After — Extend by Adding a Class, Not Editing One

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

public sealed class RegularCustomerDiscount : IDiscountPolicy
{
    public decimal Apply(decimal total) => total;
}

public sealed class VipDiscount : IDiscountPolicy
{
    public decimal Apply(decimal total) => total * 0.90m;
}

public sealed class EmployeeDiscount : IDiscountPolicy
{
    public decimal Apply(decimal total) => total * 0.80m;
}

// ─── Six months later: a new discount type ───
// No existing file above is touched. This is the ONLY new code.
public sealed class SeasonalDiscount(decimal seasonalRate) : IDiscountPolicy
{
    public decimal Apply(decimal total) => total * (1 - seasonalRate);
}

// ─── Consumer depends only on the abstraction ───
public class CheckoutService(IDiscountPolicy discountPolicy)
{
    public decimal CalculateTotal(decimal subtotal) => discountPolicy.Apply(subtotal);
}

RegularCustomerDiscount, VipDiscount, and EmployeeDiscount are never opened again to add SeasonalDiscount. CheckoutService never changes either — it was written once, against the interface, and stays closed for modification while the system stays open for extension. Whichever policy gets registered in the DI container (Lesson 124) at startup is the one CheckoutService uses; adding a new policy is purely additive.

How It Works — Liskov Substitution Principle

Lesson 074 introduced LSP briefly, in the context of polymorphic collections: any subtype must be usable anywhere the base type is expected, "without the caller needing to know or care which one it actually got." Here's the deeper version, with the example that made this principle famous.

A Genuine LSP Violation — Square : Rectangle

Geometrically, a square is a rectangle — every square satisfies the definition of a rectangle. It seems natural to model it with inheritance:

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

public class Square : Rectangle
{
    // To keep a square a square, both sides must move together...
    public override double Width
    {
        get => base.Width;
        set { base.Width = value; base.Height = value; }
    }
    public override double Height
    {
        get => base.Height;
        set { base.Height = value; base.Width = value; }
    }
}

The code compiles. Square genuinely overrides every member Rectangle declares. But watch what happens to a caller written against the base type:

void Resize(Rectangle rectangle)
{
    rectangle.Width = 5;
    rectangle.Height = 10;
    // Anyone reading this expects Area to be 50 for ANY Rectangle.
    Debug.Assert(rectangle.Area == 50);
}

Resize(new Rectangle());  // Area = 50 
Resize(new Square());     // Area = 100  — setting Height silently overwrote Width

Resize never mentions Square. It was written entirely against the Rectangle contract: "width and height are set independently." That is a completely reasonable expectation to build on a class called Rectangle with two independent settable properties — and Square breaks it, silently, without throwing, without a compiler warning. This is exactly what LSP forbids: a subtype whose behavior violates assumptions callers are entitled to make about the base type.

The Fix — Don't Force an Inheritance Relationship the Contract Can't Support

public interface IShape
{
    double Area { get; }
}

public sealed class Rectangle(double width, double height) : IShape
{
    public double Width { get; } = width;
    public double Height { get; } = height;
    public double Area => Width * Height;
}

public sealed class Square(double side) : IShape
{
    public double Side { get; } = side;
    public double Area => Side * Side;
}

Neither class inherits from the other. Both implement IShape, which only promises an Area — a contract both types can honor without lying. There's no inheritance relationship to violate, because there's no shared base contract making a promise ("independently settable width and height") that one of the subtypes can't actually keep. The mathematical "is-a" relationship between squares and rectangles was real; the behavioral substitutability that LSP requires was not — and LSP cares about behavior, not geometry.

Simple Example — Spotting a Violation Fast

A quick smell test for each of the three principles covered in depth here:

• SRP smell: you can't describe the class in one sentence without using the word "and" for unrelated concerns — "calculates pay and formats PDFs and sends email."
• OCP smell: adding a new case means opening a switch statement or a chain of if/else if that already handles several other, unrelated cases.
• LSP smell: a subtype's override throws NotSupportedException, silently does nothing, or changes state the base class contract didn't say it would change.

Real-World Example — All Five, Together, in One Payment Flow

A payment-processing feature in a production order system, applying all five principles at once:

// D — depend on abstractions, not concrete gateways (Lesson 081)
public interface IPaymentGateway
{
    Task<PaymentResult> ChargeAsync(decimal amount, string customerId);
}

// I — small, focused contract; a reporting screen never needs ChargeAsync (Lesson 079)
public interface IPaymentAuditReader
{
    Task<IReadOnlyList<PaymentRecord>> GetRecentAsync(string customerId);
}

// O — new gateways are added, never by editing this file
public sealed class StripeGateway : IPaymentGateway
{
    public Task<PaymentResult> ChargeAsync(decimal amount, string customerId) => /* Stripe SDK call */ default!;
}

public sealed class PayPalGateway : IPaymentGateway // added later — zero edits above
{
    public Task<PaymentResult> ChargeAsync(decimal amount, string customerId) => /* PayPal SDK call */ default!;
}

// L — any IPaymentGateway must genuinely attempt a charge and return a real result;
// a gateway that just returns success without charging would violate the contract
// callers are entitled to rely on, even though it "compiles."

// S — OrderCheckoutService has exactly one reason to change: checkout orchestration logic.
// It does not calculate tax, does not format receipts, does not manage inventory.
public sealed class OrderCheckoutService(IPaymentGateway gateway, ILogger<OrderCheckoutService> logger)
{
    public async Task<PaymentResult> CheckoutAsync(Order order)
    {
        logger.LogInformation("Charging {CustomerId} for {Amount}", order.CustomerId, order.Total);
        return await gateway.ChargeAsync(order.Total, order.CustomerId);
    }
}

Notice how naturally the five principles reinforce each other here: DIP is what makes OCP possible (you can only add a new gateway without editing consumers because the consumer depends on an abstraction); ISP is what keeps that abstraction from growing bloated as more payment-related features get added; SRP is what keeps OrderCheckoutService from absorbing tax logic or receipt formatting "while we're in here anyway"; and LSP is the silent assumption underneath all of it — that any IPaymentGateway you plug in actually behaves like a payment gateway.

Analogy

Under the Hood — The Design Reasoning

Every SOLID principle spends a little complexity now to buy a lot of safety later. That trade only pays off for code that will actually be touched again — which, for most production systems, is almost all of it.

Common Confusion

1. "SRP means a class should have only one method" — no

SRP counts reasons to change, not method count. A class with fifteen small, related methods that all serve one stakeholder (say, all of them exist purely to answer "is this order valid?") has a single responsibility. A class with two methods serving two unrelated stakeholders does not.

2. "Open/Closed means I can never edit a file again" — no

You will absolutely still edit code — fixing a genuine bug inside VipDiscount is not an OCP violation, because you're correcting existing behavior, not bolting a new, unrelated case onto a growing conditional. OCP is about how you accommodate new variants, not a ban on all future edits everywhere.

3. "LSP is just about method signatures matching" — no

The compiler already enforces signature compatibility; that's not what LSP adds. LSP is about behavioral compatibility — preconditions the subtype can't strengthen, postconditions it can't weaken, invariants of the base type it can't quietly break. Square matched every signature Rectangle declared and still violated LSP.

Common Mistakes

Mistake 1 — Over-applying SRP into an anemic mess

Splitting PayrollCalculator further into GrossPayCalculator, TaxCalculator, DeductionCalculator, and a coordinator to glue them, when finance treats all of that as one indivisible rule set that only ever changes together.

Split along genuine, independent reasons to change — not just because a class has more than one method or more than one field.

Mistake 2 — Applying OCP speculatively, before a second case exists

Building an IDiscountPolicy abstraction, a factory, and a registration system for a discount calculation that has exactly one rule today and no plan for a second one. This is complexity paid for a benefit that may never arrive.

It's often fine to write the simple, direct version first (a plain method, even an if) and introduce the OCP-friendly abstraction once a second, genuinely different variant actually shows up. Premature OCP is speculative generality — a real cost with no guaranteed payoff.

Mistake 3 — An override that throws instead of honoring the contract

public class ReadOnlyReportRepository : IRepository<Report>
{
    public Task DeleteAsync(Guid id) => throw new NotSupportedException(); //  LSP violation
}

Any caller that holds an IRepository<Report> and calls DeleteAsync — which the interface promises it can — gets an exception instead of the behavior the contract advertised.

This is usually a sign the interface itself is too fat (an ISP problem, Lesson 079) — split a narrower IReadOnlyRepository<T> out, so a read-only implementation never has to fake support for a member it can't honor.

When Should I Use It?

• Apply deliberately in code that will genuinely be maintained and extended — most production application code, especially business logic and anything with more than one team touching it.
• Apply lightly, or skip, for a one-off script, a proof of concept, or code you already know will be deleted in a week. Extra abstraction there is pure cost with no future payoff to recoup it.
• Treat SOLID as heuristics, not laws. They're a lens for asking "will this be painful to change later?" — not a checklist to satisfy for its own sake. Forcing every principle onto every class, everywhere, produces its own kind of mess (more on this directly in Lesson 239's caveat about "pattern-itis").

Mental Model

Key Takeaway

Check Your Understanding

You've seen all five SOLID principles and gone deep on S, O, and L. Let's check that the distinctions actually stuck.

You now hold all five SOLID principles as one coherent toolkit — the foundation the rest of this architecture module builds on.

dotnetmadeeasy.com — Learn C# and .NET, the right way.