Loading
Loading
Low-level design is the layer between 'which services exist' and 'which line runs': what types live inside one service, what each is responsible for, and how they reach each other. This track builds the vocabulary — responsibility, coupling, cohesion — then SOLID as special cases of it, then the patterns that are recurring answers to recurring problems. Every pattern is taught with the situation where it is the wrong choice.
Up next: What Low-Level Design Is
What low-level design actually decides, and the two ideas — responsibility and coupling — that every later section is about.
The two measurements every later principle is a special case of.
Encapsulation, abstraction, polymorphism and composition — as tools with costs, not as a vocabulary test.
Five principles, each with the specific pain it removes and the specific over-application that makes it harmful.
The two that do the most work, and the two most often quoted without their qualifier.
The three that describe how types relate: what a subtype owes, how wide an interface should be, and which way dependencies should point.
Creational, structural and behavioural patterns — each with the problem it solves and the situation where it is overkill.
Factory Method, Abstract Factory, Builder and Singleton — mostly about not scattering `new` through your code.
Adapter, Decorator, Facade, Composite and Proxy — four ways to put something in front of something else, and one way to treat a group as one.
Strategy, Observer, Command, State and Template Method — the patterns about what happens, and when.
A repeatable procedure for getting from a brief to a defensible design, and what to consider once it has to run for real.
Where shared mutable state comes from, how to remove it or guard it, and how to stop two requests from booking the same thing.
A race needs shared, mutable state. Take away either word and the race cannot happen — that is most of thread-safe design.
Guarding the state that must be shared: critical sections, how big a lock should be, bounded queues for handing work between threads, and how deadlock happens.
Two people click 'book' on the last seat at the same moment. Pessimistic locks, version checks, compare-and-set and idempotent commands — and when each is the right answer.
Five classic briefs worked from requirements to entities, responsibilities, relationships and patterns — with the trade-offs and the extensions that would change the model.
Members, books, copies, loans and reservations — and why the difference between a book and a copy decides the whole design.
A bank of cars, hall calls and car calls: modelling elevator state, separating dispatch from stop ordering, and keeping the controller single-threaded.
Pieces, a board, moves and rules: where polymorphism helps, where a table of directions is simpler, and why legality belongs to the game rather than the piece.
Groups, expenses, splits and settling up: money as a value object, split rules as strategies, balances as derived data, and simplifying who pays whom.
Searching availability by night, holding inventory while a guest pays, and cancellation policies that cannot change after the fact.