SOLID principles

Code that's easy to change

Software that matters keeps changing: new requirements, new integrations, bug fixes. SOLID is a set of five principles (popularized by Robert C. Martin) that make classes easier to change without breaking things. They're guidelines, not laws — use them to spot problems, not to add ceremony.

S — Single responsibility

A class should have one reason to change.

// ❌ Changes when the report format, the data source, OR the email provider changes
class MonthlyReport
{
    public void Run()
    {
        var sales = LoadSalesFromDatabase();
        var pdf = RenderPdf(sales);
        SendEmail("boss@example.com", pdf);
    }
}
 
// ✅ Each part has one job; MonthlyReport only coordinates
class MonthlyReport(ISalesRepository sales, IReportRenderer renderer, IEmailSender email)
{
    public async Task RunAsync() =>
        await email.SendAsync("boss@example.com", renderer.Render(await sales.GetMonthAsync()));
}

O — Open/closed

Open for extension, closed for modification.

A switch that grows with every new case means editing (and re-testing) the same code forever:

// ❌ Every new payment method edits this method
decimal Fee(string method, decimal amount) => method switch
{
    "card" => amount * 0.029m,
    "paypal" => amount * 0.034m + 0.35m,
    "bank" => 0.50m,
    _ => throw new NotSupportedException(),
};

Instead, put each variation behind an interface — adding a method means adding a class:

interface IFeePolicy { string Method { get; } decimal Fee(decimal amount); }
class CardFee : IFeePolicy { public string Method => "card"; public decimal Fee(decimal a) => a * 0.029m; }
// register all policies in DI; the calculator picks the matching one

This lesson's exercise applies exactly this to shipping rules.

L — Liskov substitution

Subtypes must be usable wherever their base type is expected.

If code written for Rectangle breaks when given a Square (because setting the width also changes the height), the hierarchy is wrong — even though "a square is a rectangle" in geometry. Warning signs: overrides that throw NotSupportedException, or callers checking if (x is SpecialSubtype).

I — Interface segregation

Clients shouldn't depend on methods they don't use.

// ❌ A read-only report must implement Save and Delete it never needs
interface IRepository<T> { T Get(int id); IEnumerable<T> All(); void Save(T item); void Delete(int id); }
 
// ✅ Small, focused interfaces
interface IReader<T> { T Get(int id); IEnumerable<T> All(); }
interface IWriter<T> { void Save(T item); void Delete(int id); }

D — Dependency inversion

Depend on abstractions, not concretions.

High-level policy (OrderService) shouldn't depend on low-level details (StripeClient). Both depend on an abstraction (IPaymentGateway), and the details are plugged in through dependency injection — what you did in Tracks 8 and 9. That's what makes the code testable and swappable.

Using SOLID pragmatically

• Apply the principles when code starts to hurt — a class keeps growing, every change touches the same switch, tests are impossible to write.
• Don't create an interface for every class "just in case" (YAGNI — you aren't gonna need it).
• Prefer simple, readable code over pattern-heavy code. SOLID is a means, not a goal.

Key takeaways

• S: one reason to change per class.
• O: extend behavior by adding code (new classes), not editing working code.
• L: subtypes must honor their base type's contract.
• I: small, focused interfaces.
• D: depend on abstractions; inject the details.