Object-oriented design rounds where you produce classes, interfaces, and interactions rather than infrastructure boxes and arrows.
35 published across 7 topics.
Encapsulation, inheritance versus composition, polymorphism, and where each genuinely applies.
Encapsulation earns its place when a class owns an invariant that callers would otherwise each have to enforce, and polymorphism when a conditional grows with every new requirement. Composition versus inheritance is decided on evidence: how many axes vary, and whether every inherited operation is honest.
Behaviour that needs only the object's own state, and any rule the object must never violate, belongs on the object. Services own orchestration across objects, anything requiring I/O, and the transaction boundary - which is why an entity should never hold a repository.
The five principles with realistic violations and refactorings, plus cohesion and coupling reasoning.
High-level policy should not depend on low-level detail; both should depend on an abstraction. What inverts is ownership of the interface - it belongs to the module that consumes it, not to the one that implements it, which is what reverses the direction of the source dependency.
A class violates SRP when it has more than one reason to change, not when it has more than one method; the refactor is to split along the axes that have independently churned, such as pricing rules, persistence, and presentation, and to stop splitting once each piece has its own requester.
The interface was assembled from the union of what implementations do rather than from what any one caller needs, so no implementation can honour the whole contract. Split it by client into role interfaces, working from the call sites rather than from the classes.
Factory, builder, singleton, and prototype, including when each is over-engineering.
Replace the switch with a registry the application builds once at startup: a map from discriminator to a factory, validated for duplicate and missing keys as it is constructed, injected rather than global, and with a decided answer for a type the consumer has never seen.
A constructor is the default and needs no justification. A static factory earns its place when construction can return a cached or alternative implementation, or needs a name; a builder when there are many optional fields. Singleton is usually a testability liability.
The mechanics are easy - an enum in Java, a module-level value elsewhere - and are not the interesting part. The objection is that a singleton bundles two unrelated decisions, one instance and globally reachable, and the second is what makes dependencies invisible and tests order-dependent. It also connects creational patterns to the point an interviewer is testing.
Adapter, decorator, facade, proxy, and composite as answers to concrete design pressures.
A lazy-loading proxy is a different object of a different class from its subject, so getClass comparisons, direct field reads and identity checks all see the proxy. A proxy pattern that survives defines equality by an identity key both sides answer without loading, compared through instanceof and accessors.
A composite gives leaves and containers one interface so callers recurse without branching. The two decisions that matter are whether child management appears on that shared interface, and which operations genuinely aggregate - because price, availability and delivery date do not combine the same way. It also connects tree structures to the point an interviewer is testing.
Adapter converts a type you do not own into the interface your code already speaks. Decorator adds behaviour while keeping the same interface, so wrappers stack. Facade gives callers one narrow entry point into a subsystem. Each becomes over-engineering the moment nothing on the other side varies.
Strategy, observer, state, command, and template method in interview-sized problems.
Name what varies first: channel, text, the user's channel choices and retry. A notification service then needs a channel interface (a strategy) picked from a registry, templates as data, a preference policy and a retry policy splitting transient from permanent errors. Most other design patterns add classes, not value.
Observer decouples a subject from things that react to it, which is right when the subject genuinely should not know its listeners. The costs are a control flow you cannot read from the code, listener lifetimes that leak, and an exception in one observer that silently prevents the rest from running.
Write the legal transitions down as a table first, then give the entity one entry point that consults it and no state setter at all. The design question is where the transition rules live and how side effects stay outside the decision that changed the state.
Use the strategy pattern instead of inheritance when behaviour varies independently from object identity. Composition avoids subclass explosion, enables runtime swapping and makes algorithms easier to test.
Thread-safe components, lock granularity, and immutable-object strategies.
For one stock counter, optimistic locking with a compare-and-set loop fits: read, refuse at zero, and publish the decrement only if nobody changed the value meanwhile. A lock suits a larger critical section. Prove it by arguing each sale consumes one unit, plus a stress test seen to fail on the broken code.
Shrink the critical section first, then replace the global lock with lock striping, a fixed array of locks keyed by resource hash. Lock ordering by ascending stripe index rules out deadlock for multi-resource bookings, tryLock bounds waiting, and invariants the old lock covered by accident each need an owner.
The bug is a check-then-act race condition: both threads see the seat free before either marks it taken. The lock must cover the check and the write together, scoped to one show so unrelated shows never wait, and released before payment, with a timed hold standing in for the seat while the user pays.
Thread-safe component design starts by assigning every field a policy: confined, immutable or guarded by a named lock. Method-level synchronization is not enough because atomic methods do not compose into atomic workflows.
A producer-consumer bounded buffer applies backpressure to the producer instead of letting an unbounded queue absorb overload until the process dies. Deciding what a full buffer does - block, drop, or reject - is the decision that determines how the system fails.
A deadlock is a cycle in the wait-for graph, so the design goal is a graph that cannot contain one: stop holding two locks where you can, impose one total order on acquisition everywhere you cannot, and never call unknown code while holding a lock.
Machine coding round questions such as parking lot, rate limiter, Splitwise, elevator, vending machine, and other timed build-it problems.
An in-memory pub-sub with at-least-once delivery stores each topic as an append-only log and gives every subscriber its own cursor and in-flight set. A message stays in flight until acknowledged and is redelivered after an ack timeout, so a slow subscriber only delays itself and every handler must tolerate duplicates.
A food ordering design has two lifecycles: the order moves from placed to delivered, while delivery partner assignment runs alongside and can fail and restart. Keep them separate, claim a partner atomically, rank candidates behind a strategy, and write cancellation windows as rules keyed on order state.
An elevator system splits into a state machine per lift that decides its own next floor, and a dispatcher that assigns each hall call to one lift through a pluggable strategy such as a nearest-suitable-car cost. Car buttons go straight to their lift, and one control loop owns all state, so no god class and no locks.
An in-memory job scheduler keeps one queue ordered by next run time, such as a DelayQueue, and one dispatcher thread that hands due entries to a worker pool. Recurring jobs are re-queued after each run, cancellation is a generation check on dequeue, and missed runs need a stated skip or catch-up policy.
A digital wallet stays non-negative only if the balance check and the debit happen in one critical section. Lock both wallets in a fixed order by id so concurrent transfers cannot deadlock, record every movement as a pair of entries, and make each transfer idempotent on a client key so a retry cannot pay twice.
Expire keys lazily on read and actively with a background sweep, both through the write path. For a consistent snapshot of a key-value store, copying the live map is not enough: take a brief cut, have each writer save a key's old value before changing it, and merge those saved values into the scan.
A ticket booking design models a Show that owns its seat states and a Hold with an owner, seat set and expiry. Holds are taken all-or-nothing under a per-show lock, expiry is checked lazily so no timer decides correctness, and starting payment moves the hold to a state the timer can no longer release.
Write the domain model, the interfaces and the code enforcing each invariant yourself, because the grader scores them and a mid-round change tests them. Hand the assistant bounded boilerplate such as records, an in-memory repository, a driver and test scaffolding, and review every line it returns.
Write the paragraph back as a numbered list of testable rules, mark each as build, stub or out, and turn the rule with the most interacting parts into the first test. Leave out the nouns that are only context, the features introduced with 'eventually', and every side channel the rules do not depend on.
The passing candidate said, before typing, which approach they chose, which alternative they rejected and what that choice costs. Identical code then reads as a decision rather than recall, the interviewer can redirect before the time is spent, and later follow-ups confirm rather than interrogate.
Model a Board that only stores marks and rejects illegal squares, and a Game that owns the turn and a status of in progress, won or drawn. The win check belongs inside the Game's move method, testing only lines through the square just played and running before the draw check, so a finished game refuses further moves.
In a parking lot machine coding round, scope one deterministic flow of park, unpark and charge, model Vehicle, Slot, Level, Ticket and a ParkingLot facade, then push slot allocation and pricing behind strategy interfaces so review-time variants are configuration rather than surgery.
A rate limiter machine coding solution should reject fixed-window boundary bursts, usually with a token bucket. It needs no per-request history and stores two numbers per client, but only if refill is computed lazily from a timestamp rather than by running a background thread. Use this rate limiting answer to show the decision, trade-off, and evidence rather than a memorised definition.
A Splitwise-style machine coding answer turns on one invariant: the shares of an expense must sum to the expense total exactly, in every currency, forever. That forces money into integer minor units and forces a stated rule for allocating the remainder.