Learn it in order: OOP used properly, then SOLID, then the everyday design patterns, then small systems built end to end with tests. Patterns only make sense once you have felt the problem they solve, so build a parking lot, a rate limiter and an expense splitter rather than memorising 23 diagrams.
What people tell me
I can solve DSA problems and I have built a couple of projects, but when a problem says "design a parking lot" or "design a library system" I freeze. I have watched videos on design patterns and SOLID, and I can repeat the definitions, but I do not know when to use any of them. My project code works, but it is one big file and adding anything breaks something else. I do not know where to start or in what order to learn this.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Low level design is the design of classes and their relationships inside one program; system design is the same thinking across services and databases.
- Learn in order: OOP used properly, SOLID, the four everyday patterns, then UML and refactoring, then small systems end to end.
- Learn each pattern by the problem it solves; if you cannot name the problem, you do not need the pattern.
- Build every design you draw: parking lot, rate limiter and expense splitter are three good first ones.
- Coding rounds that ask for a design test exactly this skill, so good habits pay off there too.
What low level design actually is
Low level design, usually shortened to LLD, is deciding which classes a program needs, what each one is responsible for and how they talk to each other. System design is the same kind of thinking one level up, across services, databases and networks. You need both, and LLD comes first because it is what you do every day when you write code.
The reason you freeze on "design a parking lot" is not that you are missing a pattern. It is that nobody taught you a method, and the patterns were taught before the problems they solve. Here is the order I recommend.
Step 1: relearn OOP as a tool, not as definitions
Most students learnt encapsulation, inheritance and polymorphism as exam answers. Relearn them as tools: every class should protect a rule or hide a decision. Practise three things until they are automatic:
- Make fields private and expose behaviour, such as
withdraw, instead of setters. - Replace an
if type == ...chain with an interface and a class per type. - Prefer holding another object (composition) over extending a class just to reuse code.
Step 2: SOLID as questions, not rules
Learn each SOLID principle by the smell it prevents: a class that changes for many reasons, a switch that grows every sprint, a subclass that throws "not supported", an interface nobody uses fully, a class that creates its own database connection. When you can spot the smell, you understand the principle.
Step 3: the everyday patterns first
There are 23 classic patterns, but four cover most of real work: Strategy, Observer, Command and State. Add Factory, Builder, Adapter and Decorator next. For each one, write down the problem in one sentence before you look at any code. Learn the rest well enough to recognise them.
Step 4: a method you use every time
For any design problem, go through the same steps:
- Clarify requirements and write down what is out of scope.
- List the use cases.
- Find the entities from the nouns and give each one clear responsibilities.
- Choose relationships and sketch a class diagram.
- Write the key code paths, then check them against SOLID.
Step 5: build small systems end to end
Drawing is not enough; code shows the flaws a diagram hides. Build three designs with tests: a parking lot (composition, strategies, the last-spot race condition), a rate limiter (a strategy interface and an injectable clock) and an expense splitter (split strategies and exact money). If you want a bigger final year project in this area, the receipt scanning expense splitter idea is the same design at full size.
Where to learn it on Sefism
- The Software design and clean code roadmap takes you through all of this in ten stages, with a check question and a practice prompt for every topic.
- The software design cheat sheet has SOLID, all 23 patterns with code in Java, Python, TypeScript or C#, a UML notation card and a smell to refactoring table.
- For patterns, Refactoring.Guru is the best free explanation, and MIT 6.102 Software Construction covers the fundamentals underneath.
- When you are ready for the next level, the System design roadmap is the other half of this skill.
What about coding rounds?
Some companies run a round where you design classes for a problem like a parking lot. If you have followed the steps above, that round is just another design problem. Learn this because it makes you a better engineer; the round is a side effect.
If you want someone to look at a design you have built, create a free account and book a session with me, or browse more answers on the questions page.
Was this answer helpful?
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.