I hold a design in my head before I draw a class. A request arrives. Some object already owns a piece of state. The design is whether that state is still true when the request returns.
How to read the note
Words, then what a C++ object is, then the thinking steps and the ten headings I write on a board. Then the walks. SOLID and the pattern names come after you have owners. How to apply them is next. The timed board is last.
If you are short on time, do the lot, the seat, and the cache. That is the core. The later walks are the same clothes.
The ten headings
I do not start with Vehicle, Spot, Level, Gate. That list does not say who is allowed to flip occupied. On a board I write these ten, in this order. I do not start at patterns.
- Scope. In and out. Types. Multiplicity. Pick logic. Where a race lives.
- Use cases and API. Calls, success, fail.
- Data model. What I store. The invariant in one sentence.
- Core classes. Who owns the scarce bit.
- Patterns. A name only if two ways exist.
- Sequence. One happy call.
- Concurrency. Two at once.
- Edges. Every fail on the API.
- C++ skeleton. The smallest code that holds the invariant.
- Extensions. What I put out on purpose.
One walk: a car enters a lot
Scope: park, unpark, how many free. Out: SMS, a display board, four kinds of gates. Types: bike, car, truck. Multiplicity: one lot, many floors. Logic: first fit, lowest floor. Race: two parks, one stall.
park(plate, kind) -> ticket | fullunpark(ticket) -> fee | unknown ticketfreeCount(kind) -> number
A stall is free or it is held by exactly one active ticket. A ticket points at one stall.
That is the sample. The PDF walks the same ten headings on a seat, a cache, a copy, a wallet, a lift, a rate limit, a bill, and a cab. Then C++, SOLID, Factory through Observer, and how I apply a name after the walk.