How to use this book
This is the shortest book in the series, and the only one not built from a lecture. It needs to say why up front.
The Backend from First Principles playlist names these principles exactly once. In video 1, the roadmap, at 18:23:
"...we'll look at different design principles like separation of concerns, single responsibility, open close, dependency inversion, what are the components of a business logic layer..."
Four seconds, inside a thirty-one minute video that reads the whole curriculum aloud. No later video returns to them. The playlist promises these principles and never delivers them, which is exactly why this book exists.
So the material here comes from the primary sources: Meyer in 1988, Liskov in 1987, Martin through the 1990s, Dijkstra in 1974. Every one of them is named where it is used, because the second-hand version of these principles is where almost all the confusion in this field comes from. What the video does give us is the right context, and this book keeps it: these are principles about the business logic layer, the middle of the three layers, and they are aimed at the code that holds your actual rules.
The one question
What has to change together?That is what all five of SOLID are about, and none of the usual summaries say so. Each principle is a different answer to the same question, and the question is never "is this code beautiful". It is: when a requirement changes next quarter, how far does the edit spread?
| Letter | The change it is trying to contain |
|---|---|
| S | Two people asking for different things, editing one file |
| O | Adding a case means editing the code that already worked |
| L | A subtype that makes callers check which subtype it is |
| I | A method you do not use, changing, and breaking you |
| D | The stable rules depending on the volatile detail |
If a principle does not reduce how far a change spreads, you are applying it as decoration, and this book will keep saying so.
What is in here that is not in the usual summary
Five things, and they are the reason this is a book and not a blog post.
- Martin changed the definition of SRP in 2017. The version everybody quotes is the 1990s one. The refinement is better and almost nobody knows it.
- There are two Open-Closed Principles. Meyer's and Martin's are different mechanisms, and people argue past each other because of it.
- Liskov's actual rule is four conditions, not a vibe about inheritance. Preconditions, postconditions, invariants, history.
- Coupling and cohesion came first and explain more. Constantine had the useful vocabulary twenty years before the acronym existed.
- SOLID has serious critics. Knowing the strongest argument against it is what separates someone who read the source from someone who read a slide.
The five block types
| Block | What it means |
|---|---|
| Interviewer asks | A real follow-up you should expect. Answer it out loud before reading on. |
| Senior signal | The specific sentence that separates a senior answer from a mid-level one. |
| Trap | A common answer that sounds right and is wrong. |
| Do this | The concrete practice, with the parameter or the number. |
| Key idea | The one thing to carry out of that section. |
The four highlighters
| Mark | Means |
|---|---|
| peach | The sentence to carry away |
| rose | The wrong answer, the thing that bites |
| mint | The correct practice |
| pink | A definition, at the point it is first defined |
A suggested route
- Read Part I first and do not skip it. The five letters make far more sense after coupling and cohesion than before.
- Part II is reference. One section per idea. Read it with your own code open.
- Part III is the part that stops you doing damage with Part II. It is the half of this subject that interviews actually probe.
The whole picture on one page
ONE REQUIREMENT CHANGES
│
▼
┌────────────────────────────────────────┐
│ how many files must you edit? │
└────────────────────────────────────────┘
│ │
ONE FILE ELEVEN FILES
│ │
▼ ▼
the design the design
held leaked
│
┌───────────────────────────────┴─────────────┐
│ │
WHY DID IT SPREAD? WHICH PRINCIPLE
│ WAS BROKEN?
│
┌────┴─────────────────────────────────┐
│ │
│ one file served two audiences ─────┼──▶ S
│ │
│ adding a case meant editing ─────┼──▶ O
│ the switch that already worked │
│ │
│ a subclass surprised its caller ────┼──▶ L
│ │
│ an interface carried methods ─────┼──▶ I
│ this client never called │
│ │
│ the rule imported the detail ─────┼──▶ D
│ │
└──────────────────────────────────────┘Read it in that direction, from the painful change backwards to the principle that would have prevented it. Read in the other direction, from principle to code, it produces speculative abstraction and the pain arrives anyway, wearing a factory.
Three rules govern the whole book.
- A principle is a prediction about change. "This will vary, that will not." Applying a principle where nothing varies costs you a layer and buys nothing.
- Coupling is the disease, and the five letters are treatments. If you cannot say which coupling a refactor removed, it was not a refactor.
- You are allowed to break any of them, once you can say what it will cost. That sentence is the entire difference between a mid-level and a senior answer.