Free lessons
Object-Oriented Design Lessons
Every lesson in the Object-oriented design course, free to read. Each skill has a lesson that starts simple and gets technical, and a quick revise page. Practice and progress tracking need a free account.
OOP Fundamentals
The four pillars, and the composition-vs-inheritance call every class hierarchy eventually forces.
Core OOP Concepts
- OOP Pillars & CompositionWriting code against an abstraction (Shape) instead of its concrete subtypes, so new subtypes need zero changes elsewhere.
- Encapsulation & ImmutabilityProtect an object's invariants behind its methods, avoid leaking internal state, and design value objects that never change once created.
- Polymorphism, Interfaces & Abstract ClassesHow dynamic dispatch replaces type checks, how overloading differs from overriding, and when to reach for an interface versus an abstract class.
- equals, hashCode & Object ContractsThe equals/hashCode contract, why hash-based collections depend on it, and the classic bugs: mutable keys, broken symmetry and inconsistent ordering.
SOLID Principles
Five rules of thumb for keeping a class hierarchy changeable as requirements grow, instead of increasingly fragile.
The Five Principles
- SOLID Principles FundamentalsRecognizing which SOLID principle a design violates, and why that violation will hurt later.
- Single Responsibility PrincipleGive each class one reason to change by separating responsibilities that change for different people and different reasons.
- Open/Closed PrincipleAdd new behavior by adding code, not by editing working code - using extension points such as interfaces, strategies and registries.
- Liskov Substitution PrincipleSubtypes must honor the contract of their supertype, so code written for the parent keeps working with any child.
- Interface Segregation PrinciplePrefer small, role-based interfaces so no class is forced to implement - or depend on - methods it doesn't use.
- Dependency Inversion PrincipleMake high-level policy depend on abstractions, not on concrete details, and inject those details from outside.
Design Patterns: Creational
Controlling how and when objects get constructed, instead of scattering "new" calls (and their assumptions) everywhere.
Creational Patterns
- Singleton PatternGuaranteeing exactly one instance of a class exists application-wide.
- Factory Method PatternCentralizing "which concrete class to instantiate" in one place, so callers depend only on an abstraction.
- Abstract Factory PatternProducing a whole family of related objects together, guaranteed to be mutually compatible.
- Builder PatternConstructing a complex object step by step through chainable calls, instead of a constructor with a dozen parameters.
- Prototype PatternCreating new objects by cloning an already-initialized one, instead of repeating expensive setup.
Design Patterns: Structural
Composing objects and classes into larger structures - adapting, wrapping, and simplifying - without rewriting what they already do.
Structural Patterns
- Adapter PatternTranslating one interface into another that calling code already expects.
- Decorator PatternWrapping a base object in layers, each adding one behavior, without a subclass for every combination.
- Facade PatternOffering one simple interface in front of a subsystem that needs several coordinated calls.
- Composite PatternLetting a single object and a nested tree of them be addressed through the exact same interface.
- Proxy PatternStanding in for a real object behind the same interface, controlling access to it.
Design Patterns: Behavioral
Coordinating how objects interact and hand off responsibility, without hard-coding one object's logic into another's.
Behavioral Patterns
- Observer PatternLetting subscribers react whenever a subject's state changes, without the subject knowing who they are.
- Strategy PatternMaking an algorithm swappable at runtime by delegating to an interchangeable interface.
- Command PatternTurning a request into an object you can queue, log, or undo.
- State PatternLetting an object change its own behavior as its internal state changes, without branching on that state everywhere.
- Template Method PatternFixing an algorithm's skeleton in a base class while letting subclasses fill in specific steps.
UML & Class Design Basics
Reading and drawing the class diagrams that communicate a design before any code gets written.
Data Structure Design
Combining a few data structures so that every required operation meets its own time and space budget - the "design an LRU cache" family of problems.
Design Projects: Classic Systems
Object-oriented design interviews, one project per module - the kind often run as a pair-programming or take-home exercise: clarify the scope, model the entities, build a working core in packages, and extend it when the interviewer pushes.
How to Approach an Object-Oriented Design Interview
Elevator System
Design Projects: Concurrent Systems
Design projects where correctness depends on time and threads: rate limiting, an in-memory store with expiry and transactions, a publish-subscribe queue and a task scheduler - each built against an injected clock and tested with many threads at once.
In-Memory Key-Value Store
Pub-Sub Message Queue
Start the Object-oriented design course free
No card needed. Upgrade to Pro when you want the full problem bank.
Free plan, no card · 7-day Pro trial · Cancel anytime