SOLID in practice

SOLID is five principles for code that survives change. Interviewers rarely ask you to recite them; they test them, by asking for a change at minute 40. This module shows each principle as a smell and a fix, and the two that matter most in interviews.

1. The idea

The principles were collected by Robert C. Martin. In interviews, open/closed and dependency inversion come up most, because the follow-up twist ("add a new X") tests exactly them. Each principle has its own deep-dive module next: 03a · 03b · 03c · 03d · 03e.

2. How it works

A new promotion arrives. Watch what changes in a design that breaks open/closed, and in one that follows it.

3. Try it yourself

Which principle is broken?

Five small code smells. Pick the principle each one breaks, then check.

4. In code

The "after" design: discount rules behind an interface, injected into the calculator, and a separate receipt printer. The second line of output comes from adding one class.

from __future__ import annotations
from abc import ABC, abstractmethod
from dataclasses import dataclass


@dataclass(frozen=True)
class Item:
    sku: str
    price: int   # cents
    qty: int


@dataclass(frozen=True)
class Cart:
    customer_tier: str
    items: tuple[Item, ...]

    def subtotal(self) -> int:
        return sum(i.price * i.qty for i in self.items)


# O: open for extension. A new promotion is a new class; PriceCalculator never changes.
class DiscountRule(ABC):
    @abstractmethod
    def discount(self, cart: Cart) -> int: ...


class TierDiscount(DiscountRule):
    PERCENT = {"gold": 10, "silver": 5}

    def discount(self, cart: Cart) -> int:
        return cart.subtotal() * self.PERCENT.get(cart.customer_tier, 0) // 100


class BuyTwoGetOneFree(DiscountRule):
    def __init__(self, sku: str) -> None:
        self.sku = sku

    def discount(self, cart: Cart) -> int:
        return sum((i.qty // 3) * i.price for i in cart.items if i.sku == self.sku)


# D: the calculator depends on the DiscountRule interface; the concrete rules are passed in.
class PriceCalculator:
    def __init__(self, rules: list[DiscountRule]) -> None:
        self.rules = rules

    def total(self, cart: Cart) -> int:
        return max(0, cart.subtotal() - sum(r.discount(cart) for r in self.rules))


# S: formatting a receipt is a different reason to change, so it's a different class.
class ReceiptPrinter:
    def print(self, cart: Cart, total: int) -> str:
        return f"{cart.customer_tier} customer: subtotal {cart.subtotal()}, total {total}"


if __name__ == "__main__":
    cart = Cart("gold", (Item("coffee", 400, 3), Item("mug", 1200, 1)))
    printer = ReceiptPrinter()
    print(printer.print(cart, PriceCalculator([TierDiscount()]).total(cart)))
    # A new promotion arrives: add a class, pass it in. No existing class was edited.
    print(printer.print(cart, PriceCalculator([TierDiscount(), BuyTwoGetOneFree("coffee")]).total(cart)))

interface Item { sku: string; price: number; qty: number; } // price in cents

class Cart {
  constructor(readonly customerTier: string, readonly items: Item[]) {}
  subtotal(): number { return this.items.reduce((s, i) => s + i.price * i.qty, 0); }
}

// O: open for extension. A new promotion is a new class; PriceCalculator never changes.
interface DiscountRule { discount(cart: Cart): number; }

class TierDiscount implements DiscountRule {
  private static PERCENT: Record<string, number> = { gold: 10, silver: 5 };
  discount(cart: Cart): number { return Math.floor((cart.subtotal() * (TierDiscount.PERCENT[cart.customerTier] ?? 0)) / 100); }
}

class BuyTwoGetOneFree implements DiscountRule {
  constructor(private sku: string) {}
  discount(cart: Cart): number {
    return cart.items.filter((i) => i.sku === this.sku).reduce((s, i) => s + Math.floor(i.qty / 3) * i.price, 0);
  }
}

// D: the calculator depends on the DiscountRule interface; the concrete rules are passed in.
class PriceCalculator {
  constructor(private rules: DiscountRule[]) {}
  total(cart: Cart): number { return Math.max(0, cart.subtotal() - this.rules.reduce((s, r) => s + r.discount(cart), 0)); }
}

// S: formatting a receipt is a different reason to change, so it's a different class.
class ReceiptPrinter {
  print(cart: Cart, total: number): string { return `${cart.customerTier} customer: subtotal ${cart.subtotal()}, total ${total}`; }
}

const cart = new Cart("gold", [{ sku: "coffee", price: 400, qty: 3 }, { sku: "mug", price: 1200, qty: 1 }]);
const printer = new ReceiptPrinter();
console.log(printer.print(cart, new PriceCalculator([new TierDiscount()]).total(cart)));
// A new promotion arrives: add a class, pass it in. No existing class was edited.
console.log(printer.print(cart, new PriceCalculator([new TierDiscount(), new BuyTwoGetOneFree("coffee")]).total(cart)));

import java.util.List;
import java.util.Map;

record Item(String sku, int price, int qty) {} // price in cents

record Cart(String customerTier, List<Item> items) {
    int subtotal() {
        return items.stream().mapToInt(i -> i.price() * i.qty()).sum();
    }
}

// O: open for extension. A new promotion is a new class; PriceCalculator never changes.
interface DiscountRule {
    int discount(Cart cart);
}

class TierDiscount implements DiscountRule {
    private static final Map<String, Integer> PERCENT = Map.of("gold", 10, "silver", 5);

    public int discount(Cart cart) {
        return cart.subtotal() * PERCENT.getOrDefault(cart.customerTier(), 0) / 100;
    }
}

class BuyTwoGetOneFree implements DiscountRule {
    private final String sku;

    BuyTwoGetOneFree(String sku) {
        this.sku = sku;
    }

    public int discount(Cart cart) {
        return cart.items().stream().filter(i -> i.sku().equals(sku)).mapToInt(i -> (i.qty() / 3) * i.price()).sum();
    }
}

// D: the calculator depends on the DiscountRule interface; the concrete rules are passed in.
class PriceCalculator {
    private final List<DiscountRule> rules;

    PriceCalculator(List<DiscountRule> rules) {
        this.rules = rules;
    }

    int total(Cart cart) {
        return Math.max(0, cart.subtotal() - rules.stream().mapToInt(r -> r.discount(cart)).sum());
    }
}

// S: formatting a receipt is a different reason to change, so it's a different class.
class ReceiptPrinter {
    String print(Cart cart, int total) {
        return cart.customerTier() + " customer: subtotal " + cart.subtotal() + ", total " + total;
    }
}

public class Main {
    public static void main(String[] args) {
        Cart cart = new Cart("gold", List.of(new Item("coffee", 400, 3), new Item("mug", 1200, 1)));
        ReceiptPrinter printer = new ReceiptPrinter();
        System.out.println(printer.print(cart, new PriceCalculator(List.of(new TierDiscount())).total(cart)));
        // A new promotion arrives: add a class, pass it in. No existing class was edited.
        System.out.println(printer.print(cart, new PriceCalculator(List.of(new TierDiscount(), new BuyTwoGetOneFree("coffee"))).total(cart)));
    }
}

Output (the same in all three languages)

gold customer: subtotal 2400, total 2160
gold customer: subtotal 2400, total 1760

5. In the interview

• Name the principle when you use it, briefly: "pricing rules go behind an interface so new promotions don't touch the calculator (open/closed)".
• Inject dependencies through the constructor. It makes the design testable, and interviewers notice.
• Don't over-apply. Five interfaces for a tic-tac-toe board is worse than none. Use SOLID where change is likely.
• Liskov is the subtle one: the classic example is Square extending Rectangle, which breaks callers that set width and height independently.

One class through all five

A hotel's CheckoutDesk.checkout(stay) adds up the nights, applies loyalty discounts in a switch on the guest's tier, formats the invoice as a PDF, charges the card with new CardClient(key), and emails the guest. Each principle asks one question of it:

The order helps: separating responsibilities first shows where extension points belong, and the interfaces from the last two steps are the seams you test through. In an interview, apply only the two or three that the prompt's likely changes call for.

Saying it out loud

Interviewers listen for the problem before the label. A sentence shape that works: what you notice → what it will cost → what you'll change, and only then the principle's name.

If asked "would you always do that?", give the condition: "Only because tiers change monthly here. With two fixed tiers, the switch would be simpler."

Questions interviewers ask about SOLID

6. Remember it

7. Common mistakes

8. Practice exercise (25 minutes)

1. Add a rule (5 min). Write a ThresholdDiscount ($5 off over $50) for the code below. Did anything else change?
2. Find a god class (10 min). In code you know, list a class's reasons to change. Split one out.
3. Spot Liskov (5 min). Find a subclass that can't stand in for its parent.
4. Inject (5 min). Find a new X() inside business logic and pass it in instead.

9. Self-check quiz

10. Go deeper