Low level design
High level design is the boxes: a cache here, a queue there, a database behind it. Low level design is what is inside one box. Which classes exist, what each one is allowed to know, and what happens to the code when the requirement changes next month.
This series teaches that, and it teaches TypeScript on the same pages. Every idea is shown in real TypeScript, and every page ends with a list of the syntax it just used. You do not need to know TypeScript to start. You need to be able to read JavaScript.
How a page works
Every page has the same five parts, so by the third one you know where to look.
- Something that went wrong. A bug, an outage, a three week estimate. The idea on the page is the fix for it.
- One picture to keep. An ATM, a travel plug, a traffic signal. A definition is gone by the weekend. The picture is still there in the interview.
- Before and after code. The version that hurts, then the version that does not, in TypeScript you can paste and run.
- The TypeScript you just picked up. Every new piece of syntax on the page, with one line on what it means.
- A checkpoint and a 60 second version. Three questions, then what you would say out loud if asked to explain it.
Each code block in this section is compiled with strict on and then run, by a script,
before the page ships. The output written next to a console.log is the output it
printed. A line marked // Error: is one the compiler really rejects, with that
message.
Start here
If TypeScript is new to you, read this first. It is the 20 minutes of the language that everything else stands on.
Object oriented programming
The four pillars, each as an answer to one question about your code. Start with the overview.
SOLID principles
Five rules of thumb for code that has to keep changing. Start with the overview.
Design patterns
The ten you will meet most, in real code and in interviews. Start with the overview.
In what order
Top to bottom. The pages build on each other: SOLID assumes you know what an interface is, and the patterns assume you know why you would depend on one.
At one page a day it is a little over three weeks. If you have an interview sooner, three pages a day gets you through in eight days, and the revision table below is for the night before.
Type the snippets out. Reading TypeScript and writing it are different skills, and only one of them is tested.
Revision: every picture on one screen
Cover the right hand column and see how many you can say.
| Idea | The picture | In one line |
|---|---|---|
| The four pillars | A PIE | Abstraction, Polymorphism, Inheritance, Encapsulation. |
| Encapsulation | An ATM | Keep the data private. Every change goes through a method that checks it. |
| Abstraction | A switch on the wall | Show what it does. Hide how. |
| Inheritance | A family recipe | The child gets everything, then adds or changes a step. |
| Polymorphism | The horn | Same call, different object, different behaviour. |
| Single responsibility | The chef does not do the accounts | One class, one team with a reason to change it. |
| Open closed | An extension board | Add behaviour by adding code, not by editing code that works. |
| Liskov substitution | The substitute fielder | A subclass works anywhere its parent works. |
| Interface segregation | The TV remote | Nobody depends on methods they do not use. |
| Dependency inversion | The wall socket | Business logic depends on an interface. The database plugs into it. |
| Singleton | The stadium scoreboard | One instance, shared by everyone. |
| Factory | The restaurant counter | Ask by name. One place decides which class to build. |
| Builder | The chaat counter | Named steps, then build() gives a finished, valid object. |
| Adapter | The travel plug | Make what you cannot change fit the interface you already have. |
| Decorator | Add-ons on a dosa | Wrap with the same interface and add a little behaviour. |
| Facade | The hotel reception | One simple front door to many classes. |
| Strategy | Car, bike or walk in Maps | Interchangeable algorithms behind one interface. |
| Observer | The bell icon | One announces. Subscribers are told. |
| State | The traffic signal | Behaviour depends on the current state, and each state is a class. |
| Command | The order slip | A request as an object: queue it, log it, undo it. |
What is coming
Design questions, worked end to end the way the HLD section does them: a parking lot, a expense splitting app, a movie ticket booking flow, an elevator. Then a few more patterns that earn their place, starting with proxy, chain of responsibility and template method.
