SOLID: Designing for Change

SOLID is a famous set of five design principles for writing object-oriented code that stays flexible and easy to extend. You don't need to master them as a beginner — you need to recognize the names when they come up and grasp the single idea they all serve: build code that's open to change without rewrites.

The name is an acronym, one letter per principle. We'll take them in pairs and then name the thread that ties them together. Don't worry about applying them yet; aim to recognize them.

A picture for the whole set: Lego bricks with standard studs. Because every brick connects the same agreed way, you can add and swap pieces freely, without re-gluing the whole model. SOLID code is built to be extended like that.

Letter	Principle	In plain English
S	Single Responsibility	Each part should do just one job
O	Open/Closed	Extend behavior without modifying existing code
L	Liskov Substitution	A subtype should work wherever its base type does
I	Interface Segregation	Small, focused interfaces over big general ones
D	Dependency Inversion	Depend on abstractions, not concrete details

S and O: One Job, Open to Extension

Single Responsibility says each part should have one reason to change — one job. A class that handles both saving data and formatting screens has two jobs and will be pulled in two directions. Open/Closed says code should be open to extension but closed to modification: you should be able to add new behavior by adding new code, not by rewriting (and risking breaking) what already works.

L and I: Substitutable and Focused

Liskov Substitution says if something claims to be a kind of X, it must behave like an X everywhere an X is expected — no nasty surprises when you swap it in. Interface Segregation says prefer small, focused interfaces (sets of capabilities) over one giant interface that forces parts to depend on methods they don't use. Both keep parts honest and loosely connected.

D: Depend on Abstractions

Dependency Inversion is the one you'll hear most. It says code should depend on abstractions — general ideas — rather than concrete details. Instead of the order code depending directly on "email", it depends on a general "notifier" idea, and email is just one thing that fills that role. Swap in a different notifier later and the order code never changes. This is the loose-coupling principle from Chapter 5, made into a coding rule.

The Common Thread

All five serve one goal: reduce the blast radius of change. Each principle, in its own way, keeps a change from rippling out and breaking distant code. That's why SOLID is really an elaboration of coupling and cohesion: focused parts, loose connections, and clear contracts, so the system bends instead of breaking. You don't have to apply all five perfectly — the habits behind them help any codebase.

Cadence shows the D in action. Its notification code depends on a generic "Notifier" idea, not on email specifically. So when the team adds push notifications, they add a new brick that fills the Notifier role — the habit and reminder code that use a notifier never change. A new capability slots in like a Lego piece, exactly as SOLID intends.