FROM OBJECTS TO WORKING SYSTEMSUnderstand
Understand
Low-Level Design.
Learn to give every object a clear responsibility. Explore the principles, patterns, and decisions behind maintainable software.
Next up · What Is Low-Level Design
0 / 66topics completed
11 sections · 23 classic patterns
55 guided labs · 3 case studies
YOUR LEARNING PATH
66 of 66 topicsA foundation for every design decision.
01Introduction0 / 5
- not-startedWhat Is Low-Level DesignLow-level design turns a small set of requirements into explicit responsibilities, contracts, objects, and state transitions that a programmer can implement and test.8 min
- not-startedLLD vs HLDHigh-level design allocates system responsibilities across services and infrastructure. Low-level design specifies the contracts and behavior inside a chosen boundary.8 min
- not-startedLearning RoadmapLearn the meaning of objects and contracts before memorizing patterns. Revisit the same small domain from several viewpoints so diagrams, code, and tests reinforce each other.8 min
- not-startedInterview FormatsAn object-oriented design discussion and a machine-coding exercise reward related skills but produce different deliverables. Clarify the format before choosing how much code or notation to write.8 min
- not-startedIntroduction to Design PatternsA design pattern names a recurring arrangement of responsibilities and its tradeoffs. Recognizing the problem is more valuable than reproducing a class diagram from memory.8 min
02OOP Fundamentals0 / 7
- not-startedClasses and ObjectsA class defines behavior and construction rules; an object is one identity with its own current state. Two objects built from one class need not share their mutable fields.12 min
- not-startedEnumsAn enumeration names a closed set of domain choices. Validate external values before treating them as members; a label alone does not enforce legal state transitions.12 min
- not-startedInterfacesAn interface describes what a caller may request without choosing the concrete implementation. Method names, inputs, outputs, and failure behavior all belong to the contract.12 min
- not-startedEncapsulationEncapsulation places state behind operations that preserve a documented invariant. Hiding a field is useful when callers must not bypass the rules that make the object valid.12 min
- not-startedAbstractionAbstraction exposes the essential operation and keeps the implementation mechanism behind a boundary. It lets a caller explain what it needs without knowing the steps used to provide it.12 min
- not-startedInheritanceInheritance creates a subtype that receives behavior from a base class. Use it when the child can honor the base contract, not merely because two classes happen to share a few lines.12 min
- not-startedPolymorphismPolymorphism lets the same operation select behavior from the object receiving it. A caller can process different implementations without an expanding switch on concrete type names.12 min
03Class Relationships0 / 5
- not-startedAssociationAssociation means one object knows or communicates with another. The link says nothing by itself about who owns the other object or controls its lifetime.12 min
- not-startedAggregationAggregation models a whole containing parts that can outlive or be shared beyond that whole. The hollow diamond describes a domain ownership decision, not a garbage-collector instruction.12 min
- not-startedCompositionComposition assigns an exclusive part to a whole. In a model, the whole controls the part’s lifecycle; deleting a reference in a garbage-collected language is not sufficient to express a business deletion.12 min
- not-startedDependencyA dependency is a temporary use of another abstraction to perform an operation. It is weaker than storing a long-lived association and should point from the user toward what it needs.12 min
- not-startedRealizationRealization states that a concrete implementation fulfills an abstraction. In UML, a dashed line with a hollow triangle points from the implementation toward the contract.12 min
04Design Principles0 / 7
- not-startedDRYDRY prevents the same business knowledge from being maintained in several places. Similar-looking syntax is not automatically the same knowledge; extract a shared rule only when the reasons to change are the same.12 min
- not-startedKISSKeep the design as simple as the actual requirements allow. Simplicity is not missing validation: a short direct algorithm with explicit boundaries can be easier to reason about than a configurable framework.12 min
- not-startedYAGNIYou Aren’t Gonna Need It asks for evidence before adding speculative capabilities. Defer uncertain extensions while keeping a clear boundary that can support a real future requirement.12 min
- not-startedLaw of DemeterA caller should talk to its immediate collaborators through meaningful operations rather than navigate their internal object graphs. This reduces how many structural details one change can break.12 min
- not-startedSeparation of ConcernsSeparate decisions with different responsibilities so one can change without disturbing the others. In a small program, functions may be enough; separation does not require a service for every operation.12 min
- not-startedCoupling and CohesionCohesion describes how strongly a component’s responsibilities belong together. Coupling describes what one component must know about another. Aim for focused responsibilities and deliberate, narrow dependencies.12 min
- not-startedComposition over InheritanceComposition assembles a behavior from collaborators that can vary independently. Favor it when an inheritance hierarchy would multiply subclasses for every combination of policies.12 min
05SOLID Principles0 / 5
- not-startedSingle ResponsibilityA module should have one coherent reason to change. Identify the stakeholders and policies that drive changes; counting methods does not reveal whether a responsibility is cohesive.12 min
- not-startedOpen/ClosedKeep stable policy closed to repeated modification while allowing a known variation point to be extended. Choose that boundary from actual change pressure rather than anticipating every possible extension.12 min
- not-startedLiskov SubstitutionA subtype must preserve the expectations established by its base contract. Matching method names is insufficient if an implementation strengthens preconditions, weakens guarantees, or breaks invariants.12 min
- not-startedInterface SegregationClients should depend only on capabilities they actually use. A focused contract avoids forcing implementations to fake or reject unrelated operations.12 min
- not-startedDependency InversionHigh-level policy should depend on a stable abstraction rather than directly construct a low-level detail. Both policy and detail agree on the boundary contract.12 min
06UML0 / 5
- not-startedClass DiagramA class diagram describes types, their operations, and the relationships between them. It is a structural view, not a timeline of method calls or a picture of every runtime object.12 min
- not-startedUse Case DiagramA use-case diagram describes the goals external actors pursue through a system boundary. Actors represent roles, and use cases describe externally meaningful outcomes rather than internal methods.12 min
- not-startedSequence DiagramA sequence diagram orders messages between participants over time. Lifelines identify collaborators; calls and replies show how a use case crosses responsibility boundaries.12 min
- not-startedActivity DiagramAn activity diagram shows control flow through actions, guarded decisions, and outcomes. Use it to reason about conditions before committing side effects.12 min
- not-startedState Machine DiagramA state-machine diagram expresses legal lifecycle states and the events that transition between them. A guard restricts a transition; a status field alone does not enforce the model.12 min
07Creational Patterns0 / 5
- not-startedSingletonA singleton controls access to one shared instance within a specified scope. It does not create one instance across browser tabs, operating-system processes, or distributed deployments.12 min
- not-startedFactory MethodFactory Method moves a product creation decision into an overridable operation. The creator’s workflow can use the product contract without knowing its concrete class.12 min
- not-startedAbstract FactoryAbstract Factory creates related products as a coherent family. It is useful when the client should not mix implementations that must work together.12 min
- not-startedBuilderBuilder assembles a complex value through named construction steps. The finished product should not accidentally remain coupled to mutable construction state.12 min
- not-startedPrototypePrototype creates a new object by copying an existing configured object. The copy contract must identify which parts are shared and which mutable parts become independent.12 min
08Structural Patterns0 / 7
- not-startedAdapterTranslate an existing API into the contract your client already understands. An adapter preserves the client’s vocabulary while isolating vendor-specific units and return shapes.12 min
- not-startedFacadeA facade exposes a small use-case operation over several collaborating components. It simplifies a client’s workflow while leaving the subsystem’s responsibilities intact.12 min
- not-startedDecoratorDecorator adds behavior around an object while preserving the same client-facing operation. Wrappers compose dynamically, and their order can matter.12 min
- not-startedCompositeComposite gives leaves and containers a common operation so a client can work with one item or a whole tree uniformly.12 min
- not-startedProxyA proxy controls access to a real object while preserving its interface. It can authorize, defer creation, or cache access, but it must not silently weaken the original contract.12 min
- not-startedBridgeBridge separates an abstraction from an implementation dimension so both can vary independently. It is planned as part of the design rather than added only to reconcile an existing mismatch.12 min
- not-startedFlyweightFlyweight shares immutable intrinsic state across many logical objects while keeping per-use extrinsic state outside the shared object.12 min
09Behavioral Patterns0 / 11
- not-startedStrategyStrategy makes a family of algorithms interchangeable behind one operation. The context delegates a decision to the selected strategy rather than branching over every concrete algorithm.12 min
- not-startedIteratorIterator separates traversal state from the collection being traversed. Independent iterators can walk the same collection without consuming one another’s position.12 min
- not-startedObserverObserver lets a publisher notify registered subscribers without naming every concrete listener in its update logic. Subscription lifetime and notification ordering are part of the contract.12 min
- not-startedCommandCommand packages a request with the information needed to execute it. Supporting undo requires capturing the prior state or a valid inverse at execution time.12 min
- not-startedStateState delegates behavior to the current lifecycle state. A transition changes what the context is allowed to do next, rather than merely changing a status label.12 min
- not-startedTemplate MethodTemplate Method fixes the order of a workflow in a base operation while allowing selected steps to vary. Subclasses specialize hooks without rewriting the whole algorithm.12 min
- not-startedChain of ResponsibilityA chain passes a request through ordered handlers until one accepts it or the chain ends. The order and the unhandled result must be explicit.12 min
- not-startedVisitorVisitor moves an operation across a stable set of element types into a separate object. Each element directs the visitor to its type-specific operation.12 min
- not-startedMediatorMediator centralizes collaboration rules among peers so those peers do not need to reference every other participant. It coordinates behavior, not necessarily every piece of state.12 min
- not-startedMementoMemento captures an originator’s state so it can be restored without exposing the internal representation to the caretaker. The saved state must not change when the live object changes.12 min
- not-startedInterpreterInterpreter represents a small grammar as expression objects and gives each grammar rule an evaluation operation. Keep the grammar limited and explicit; a full programming language needs stronger parsing and execution machinery.12 min
10Interview Preparation0 / 6
- not-startedObject-Oriented Design InterviewsLead an OOD discussion from requirements to invariants, then to a small model and a demonstrable interaction. Make design choices traceable to the problem rather than to a memorized pattern.8 min
- not-startedMachine-Coding InterviewsDeliver a runnable, testable core before investing in optional framework features. The quality of the public contract matters more than the number of classes created under time pressure.8 min
- not-startedEntity IdentificationAn entity has an identity that persists as its attributes change. A value is usually described by its contents. Distinguishing them clarifies equality, ownership, and lifecycle decisions.8 min
- not-startedClean CodeReadable code makes contracts, responsibilities, and failure paths easy to locate. Short functions are helpful when they express a coherent idea, not when they merely move complexity elsewhere.8 min
- not-startedPattern SelectionSelect a pattern by the change it isolates and the contract it preserves. A pattern is a design option with costs, not an interview keyword that makes an implementation correct.8 min
- not-startedConcurrency ReasoningConcurrency matters when operations can overlap across an invariant boundary. Identify the shared state and the atomic decision before choosing a lock, queue, transaction, or immutable model.8 min
11Case Studies0 / 3
- not-startedParking LotModel parking as controlled state transitions over independently identifiable vehicles and spaces. Allocation policy decides compatibility; the lot protects occupancy and ticket uniqueness.18 min
- not-startedVending MachineA vending machine coordinates credit, stock, and purchase outcomes through explicit state transitions. A failed selection must preserve both money and inventory until a successful purchase or cancellation.18 min
- not-startedNotification ServiceA notification service separates subscription policy, delivery selection, and provider translation. A successful local dispatch is not proof that a real human read a message.18 min