OOD, UML & SOLID

1 · Inheritance vs composition essential

Here's a mistake almost everyone makes once, and only once. You have a User class. You need an AdminUser, so naturally you subclass it. Then a GuestUser, subclass again. Then PremiumUser, BannedUser, PremiumAdminUser… and suddenly you need a user who is both premium and a guest, and your inheritance tree has no branch for that. You end up copy-pasting methods or building a tangle of five-level-deep subclasses that nobody can follow. The code got rigid the moment you chose "is-a" for something that was really "has-some-traits". That day teaches you the single most important habit in object-oriented design: reach for composition first.

Think about how you'd describe a car to a child. You wouldn't say "a car is a type of engine" — that's nonsense. You'd say "a car has an engine, and wheels, and a stereo." That everyday phrasing is exactly the distinction that matters in code. Inheritance is "is-a": a subclass genuinely is a more specific kind of its parent (a Circle is-a Shape). Composition is "has-a": an object holds another object and delegates work to it (a Car has-a Engine). If you can say "X has a Y" more naturally than "X is a Y", you want composition.

Why does this matter so much in practice? Because inheritance welds two classes together permanently. A subclass inherits everything the parent has — its methods, its fields, its future changes — whether you wanted them or not. Change the base class and every subclass feels it, sometimes catastrophically (you'll watch that happen in the Liskov section below). Composition, by contrast, only depends on a small, chosen slice: the one or two methods you actually call on the collaborator. You can swap that collaborator for a different one at runtime, or inject a fake in a test, and nothing else notices.

The common trap worth naming: beginners reach for inheritance because it feels like it saves typing — "the parent already has these methods, so I'll just inherit them." But you're not buying convenience, you're buying a lifelong marriage to that parent's design. The seasoned move is to hold a collaborator as a field and delegate to it. "Prefer composition over inheritance" is probably the most-repeated line in all of OO design, and this is why: use inheritance only when the "is-a" is real and stable, and even then, keep the hierarchy shallow. With that instinct in mind, here are the two mechanisms side by side.

Two ways to reuse behavior. Inheritance ("is-a") ties you to a base class. Composition ("has-a") holds a collaborator you can swap. The industry rule: prefer composition — it's more flexible and testable.

composition.pyclass ConsoleNotifier:
    def send(self, msg): print(f"[console] {msg}")
class EmailNotifier:
    def send(self, msg): print(f"[email] {msg}")

class OrderService:
    def __init__(self, notifier):        # HAS-A notifier, injected
        self.notifier = notifier
    def place(self, item):
        self.notifier.send(f"order placed: {item}")

OrderService(ConsoleNotifier()).place("book")
OrderService(EmailNotifier()).place("pen")     # swap behavior, no subclassing

[console] order placed: book
[email] order placed: pen

2 · UML you'll actually use essential

Picture the last time a teammate tried to explain a system to you at a whiteboard. Within thirty seconds they were drawing boxes with arrows between them — "the client calls this service, which talks to this thing, which saves to the database." They didn't write a single line of code. That napkin sketch is UML, whether they called it that or not. UML (Unified Modeling Language) is just the shared vocabulary for those boxes and arrows, so that when you draw "A has-a B" your reader sees the same thing you meant. The whole value is thinking through the design before you've committed it to code that's expensive to unwind.

Here's the honest truth that trips up learners who've seen textbooks: UML has fourteen diagram types, and you will ignore twelve of them for the rest of your career. Trying to memorize the full notation is wasted effort — it's like learning every road sign in the world before driving to the shop. In real engineering, two diagrams do almost all the work, and they answer two different questions.

The class diagram answers "what are the pieces and how are they related?" — a static snapshot of the structure. It draws each class as a box and connects them with relationship arrows: a hollow triangle (▷) for inheritance ("is-a"), a filled diamond (◆) for composition ("has-a"). At a glance you see the shape of your design and, critically, whether your dependencies point at abstractions or concrete classes. The sequence diagram answers a different question — "in what order does this actually happen?" — a moving snapshot of one operation, following a request as it hops from object to object over time. Structure versus flow: that's the split, and most features need you to think about both.

The trap here isn't drawing the wrong diagram — it's over-drawing. Newcomers, once they discover UML, want to diagram everything with perfect notation, and the diagrams rot the moment the code changes. Don't. Treat these as disposable thinking tools: a five-minute sketch on paper or a whiteboard that clarifies which classes you need and who talks to whom, then you throw it away and write the code. Five minutes of sketching routinely saves an hour of building the wrong thing and tearing it out. The sketch below is a sequence-style view of the very OrderService you've been reading — read it as "who calls whom, in order."

Two diagrams earn their keep. A class diagram shows classes, fields, and relationships (inheritance ▷, composition ◆). A sequence diagram shows the order of calls between objects. Sketch these before coding a non-trivial feature — 5 minutes saves an hour.

3 · SOLID — Single Responsibility & Dependency Inversion intermediate

Every engineer has met the class from hell. It's 900 lines long, it's called something vague like Manager or Helper, and touching it feels like defusing a bomb — you fix the email formatting and somehow the database saving breaks, because both live in the same tangled method. Nobody wrote it that way on purpose; it grew one "just add it here" at a time. SOLID is five principles, coined by Robert C. Martin, that exist to stop that class from ever forming. You'll use two of them — the S and the D — almost every single day, so we take those first.

Single Responsibility (S) has a deceptively simple test: a class should have only one reason to change. Think of a Swiss Army knife versus a chef's knife. The Swiss Army knife does ten things adequately and is a nightmare to sharpen; the chef's knife does one thing beautifully. When a class handles both "how we calculate the invoice total" and "how we format it as HTML," it has two bosses — the finance team and the design team — who will each demand changes at different times, and their edits will collide in the same file. Split them, and each class answers to exactly one boss. The everyday tell that you've violated S is the word "and" creeping into your description of what a class does.

Dependency Inversion (D) is the one that unlocks testing, and its name confuses people, so here's the plain version: depend on what a thing promises to do, not on the specific thing that does it. When you flip a light switch you depend on the idea of "a device that turns on when I flip this" — you don't care whether it's an incandescent bulb, an LED, or a smart lamp, and you can swap them freely because the switch only ever knew the contract. In code, that means your OrderService should be typed against an abstract Notifier (the promise "I can send a message"), not the concrete EmailNotifier. Do that and the payoff is enormous: in a test you inject a FakeNotifier that just records the message, verify your logic, and never send a real email.

The common mistake is writing the dependency the "obvious" way: OrderService reaches in and constructs its own EmailNotifier() inside __init__. It works — until you try to test it and discover you can't run the test without a live mail server, or you need SMS instead and have to edit the service. The fix is dependency injection: hand the collaborator in from outside rather than building it inside. S and D are partners — S tells you where to cut a class apart, and D tells you how the resulting pieces should refer to each other (through abstractions) so the seams stay swappable. The lab below shows both working together in one small system.

The two SOLID principles you'll reach for daily. Single Responsibility: one reason to change per class. Dependency Inversion: depend on an abstraction, not a concrete class — which makes code testable (inject a fake).

solid_sd.pyfrom abc import ABC, abstractmethod

class Notifier(ABC):                       # abstraction (D)
    @abstractmethod
    def send(self, msg: str) -> None: ...

class EmailNotifier(Notifier):
    def send(self, msg): print(f"[email] {msg}")

class OrderRepository:                      # ONE job: persistence (S)
    def save(self, order): print(f"saved {order}")

class OrderService:                         # ONE job: order logic (S)
    def __init__(self, repo: OrderRepository, notifier: Notifier):
        self.repo, self.notifier = repo, notifier   # depends on abstractions (D)
    def place(self, order):
        self.repo.save(order); self.notifier.send(f"order {order} placed")

OrderService(OrderRepository(), EmailNotifier()).place("A1")

saved A1
[email] order A1 placed

4 · SOLID — Open/Closed, Liskov, Interface Segregation advanced

You know the sinking feeling. A change request comes in — "just add a new payment type" — and you open the code to find a giant if kind == "card" … elif kind == "paypal" … elif … that you now have to edit, retest, and pray you didn't break the four existing branches that were working fine in production. That dread is the smell the remaining three SOLID principles were designed to kill. Open/Closed, Liskov, and Interface Segregation are the "advanced" three not because they're hard, but because you feel their absence most sharply once a system is live and change is risky.

Open/Closed (O) sounds like a paradox — how can code be open and closed at once? The resolution: open to extension, closed to modification. The gold standard is the electrical socket in your wall. You extend what your house can do — a lamp, a charger, a vacuum — by plugging in a new device, never by rewiring the wall. The socket's contract is closed; the things you plug into it are open-ended. In code, you get there through polymorphism: define a contract (Shape.area()), and add a new Triangle by writing a new class, not by editing the total_area function that already works. The dreaded elif chain is the anti-pattern — it forces you to modify old code for every new case.

Liskov Substitution (L) is the one with a real bite, and it's about honesty. Named for Barbara Liskov, it says: anywhere the base class works, a subclass must work too — without surprising the caller. The famous cautionary tale is the Square that inherits from Rectangle. Mathematically a square is a rectangle, so the inheritance feels obviously right — and it's a trap. Because a square must keep its sides equal, setting the width secretly changes the height, which silently breaks any code written for a normal rectangle. The lesson lands hard: inheritance must honor behavior, not just resemble a shape. "Is-a in the dictionary" is not the same as "is-a safely in code."

Interface Segregation (I) is the gentlest of the three: many small, focused contracts beat one fat one. Picture a universal remote with eighty buttons when all you want is volume and channel — you're forced to deal with (and be confused by) capabilities you'll never use. A fat interface does that to your classes: implement Printer and you're suddenly forced to provide fax() and staple() methods that your simple printer can only stub out or throw from. Split the fat interface into small ones (Printer, Fax, Stapler) and each class implements only what it truly honors. The common mistake across all three is treating "it compiles and passes today's tests" as "it's well-designed" — these principles are insurance against the change that arrives next quarter. The labs below make each concrete, including the Square/Rectangle bug you can watch misbehave.

The other three. Open/Closed: add features by adding code, not editing old code. Liskov: a subtype must work anywhere its base does. Interface Segregation: many small interfaces beat one fat one.

open_closed.pyfrom abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self) -> float: ...

class Circle(Shape):
    def __init__(self, r): self.r = r
    def area(self): return 3.14159 * self.r ** 2
class Rectangle(Shape):
    def __init__(self, w, h): self.w, self.h = w, h
    def area(self): return self.w * self.h

def total_area(shapes):                     # NEVER changes when you add a shape
    return round(sum(s.area() for s in shapes), 2)

print(total_area([Circle(1), Rectangle(2, 3)]))   # add Triangle later, no edits here

9.14

liskov.py# Classic Liskov violation: Square "is-a" Rectangle mathematically, but not behaviorally.
class Rectangle:
    def __init__(self, w, h): self._w, self._h = w, h
    def set_w(self, w): self._w = w
    def set_h(self, h): self._h = h
    def area(self): return self._w * self._h

class Square(Rectangle):                    # BAD: overrides break the base's contract
    def set_w(self, w): self._w = self._h = w
    def set_h(self, h): self._w = self._h = h

def stretch_and_check(rect):
    rect.set_w(5); rect.set_h(4)
    return rect.area()                      # a caller expects 5*4 = 20

print("Rectangle:", stretch_and_check(Rectangle(1, 1)))   # 20 (correct)
print("Square:   ", stretch_and_check(Square(1, 1)))      # 16 — surprise! LSP violated
# Fix: don't inherit; model Square and Rectangle as separate Shapes (Step 3).

Rectangle: 20
Square:    16

5 · Expert — refactor a god class expert

This is the section where everything you've read stops being theory. Somewhere in almost every codebase lives a class that quietly became the center of the universe — a ReportManager that queries the database, formats the HTML, decides who to email, and sends it, all in one 200-line run() method. It didn't start that way. It started innocent, and then every new requirement got bolted onto the nearest available class because that was faster than thinking. Engineers call it a god class: an object that knows too much and does too much, so that changing anything risks breaking everything. Learning to take one apart calmly is the skill that most visibly separates a mid-level engineer from a senior one.

Here's why the god class is so dangerous, in concrete terms. Because it holds three or four responsibilities at once, it has three or four different reasons to change — and every one of those changes happens in the same file, so unrelated concerns keep colliding. You cannot test it in isolation, because to test the formatting you must also stand up a database and a mail server. You cannot reuse any part of it, because the parts are fused. It's the living embodiment of every SOLID violation at once: it breaks S (many responsibilities), it hard-codes concrete dependencies so it breaks D, and it usually can't be safely extended so it breaks O too.

The refactor is not mysterious — it's mechanical, and that's the good news. You name the verbs: list every distinct thing the class does ("it fetches, it formats, it sends"). Each verb becomes its own small class with a single responsibility (that's S). You define a tiny abstract contract for each — Source, Formatter, Sender — so nothing depends on anything concrete (that's D and I together). Finally you keep one thin orchestrator whose only job is to wire the pieces in order: send(format(fetch())). The orchestrator owns no details; it just sequences collaborators handed to it.

The mistake to avoid while doing this is trying to redesign the behavior at the same time as you restructure it — that's how refactors turn into multi-week rewrites that never ship. The discipline is: keep the output byte-for-byte identical and change only the shape. Prove it by running before and after and diffing the result. When you're done, each piece is independently testable (swap in a FakeSender), independently replaceable (a real database Source drops in unchanged), and the terrifying god class has become four boring, obvious classes — which is exactly what you want production code to be. The capstone lab below walks the full before → after.

Put it together. A god class does everything; we split it by responsibility and invert its dependencies so each part is testable in isolation. This is the single most common real-world refactor.

refactor.pyfrom abc import ABC, abstractmethod

# ---- BEFORE: one class fetches, formats, AND sends (3 responsibilities) ----
class ReportManagerBad:
    def run(self, rows):
        html = "<br>".join(str(r) for r in rows)      # formatting
        # (imagine it also queried the DB and emailed here)
        return f"[emailed] {html}"

# ---- AFTER: one responsibility each, dependencies injected ----
class Source(ABC):
    @abstractmethod
    def fetch(self): ...
class Formatter(ABC):
    @abstractmethod
    def format(self, rows) -> str: ...
class Sender(ABC):
    @abstractmethod
    def send(self, body) -> str: ...

class ListSource(Source):
    def __init__(self, rows): self.rows = rows
    def fetch(self): return self.rows
class HtmlFormatter(Formatter):
    def format(self, rows): return "<br>".join(str(r) for r in rows)
class FakeSender(Sender):                    # trivially testable
    def send(self, body): return f"[emailed] {body}"

class ReportService:                         # orchestrates; owns no details
    def __init__(self, src, fmt, sender): self.src, self.fmt, self.sender = src, fmt, sender
    def run(self): return self.sender.send(self.fmt.format(self.src.fetch()))

svc = ReportService(ListSource(["a", "b"]), HtmlFormatter(), FakeSender())
print(svc.run())                             # same output, now each part is swappable+testable

[emailed] a<br>b

class Engine:
    def __init__(self, kind): self.kind = kind
    def start(self): return f"{self.kind} engine started"

class Car:
    def __init__(self, engine): self.engine = engine   # has-a
    def start(self): return self.engine.start()

print(Car(Engine("electric")).start())   # electric engine started
print(Car(Engine("diesel")).start())     # diesel engine started

class Invoice:
    def __init__(self, items): self.items = items      # [(name, price, qty)]
    def total(self): return sum(p * q for _, p, q in self.items)

class InvoicePrinter:
    def render(self, inv):
        lines = [f"{n}: {p}x{q}" for n, p, q in inv.items]
        return "\n".join(lines + [f"TOTAL: {inv.total()}"])

inv = Invoice([("Widget", 10, 2), ("Gadget", 5, 1)])
print(InvoicePrinter().render(inv))
# Widget: 10x2
# Gadget: 5x1
# TOTAL: 25

from abc import ABC, abstractmethod

class Storage(ABC):
    @abstractmethod
    def save(self, key, value): ...

class InMemoryStorage(Storage):
    def __init__(self): self.data = {}
    def save(self, key, value): self.data[key] = value

class ReportService:
    def __init__(self, storage: Storage):   # inverted: depends on interface
        self.storage = storage
    def run(self, name, rows):
        self.storage.save(name, f"{len(rows)} rows")

fake = InMemoryStorage()
ReportService(fake).run("daily", [1, 2, 3])
print(fake.data)   # {'daily': '3 rows'}

DISCOUNTS = {}

def discount(name):
    def reg(fn): DISCOUNTS[name] = fn; return fn
    return reg

@discount("none")
def _none(price): return price
@discount("percent10")
def _p10(price): return round(price * 0.9, 2)

def checkout(price, kind="none"):
    return DISCOUNTS[kind](price)

print(checkout(100, "percent10"))   # 90.0

# Add a NEW discount without touching checkout() or existing ones:
@discount("flat5")
def _flat5(price): return max(0, price - 5)
print(checkout(100, "flat5"))       # 95

from abc import ABC, abstractmethod

# LSP violation: a Square that mutates both sides breaks Rectangle's contract
class Rectangle:
    def __init__(self, w, h): self.w, self.h = w, h
    def set_w(self, w): self.w = w
    def area(self): return self.w * self.h

# Fix: segregate to a minimal Shape interface; don't force set_w on shapes
class Shape(ABC):
    @abstractmethod
    def area(self): ...

class Square(Shape):
    def __init__(self, side): self.side = side
    def area(self): return self.side ** 2

def total_area(shapes): return sum(s.area() for s in shapes)
print(total_area([Rectangle(2, 3), Square(4)]))   # 6 + 16 = 22
# Rectangle isn't a Shape subclass here, but both honor area(); duck typing works.

class Parser:
    def parse(self, line):
        name, amt = line.split(",")
        return {"name": name, "amt": float(amt)}

class Pricing:
    def total(self, records): return sum(r["amt"] for r in records)

class Repo:
    def __init__(self): self.saved = []
    def save(self, total): self.saved.append(total)

class OrderService:                          # was the god class
    def __init__(self, parser, pricing, repo):
        self.parser, self.pricing, self.repo = parser, pricing, repo
    def process(self, lines):
        records = [self.parser.parse(l) for l in lines]
        total = self.pricing.total(records)
        self.repo.save(total)
        return total

repo = Repo()
svc = OrderService(Parser(), Pricing(), repo)
print(svc.process(["a,10", "b,5"]))   # 15.0
print(repo.saved)                     # [15.0]

Knowledge check check yourself