Object Oriented Design Principles Questions

Technical principles for designing object oriented systems that are maintainable, extensible, and testable. Topics include single responsibility, open closed, Liskov substitution, interface segregation, and dependency inversion principles; composition versus inheritance trade offs; designing clear and minimal public interfaces and application programming interfaces; separation of concerns, low coupling and high cohesion; use of design patterns where appropriate; strategies for dependency management and dependency injection; and practices that improve testability such as designing for mocking and modularity. Interviewers evaluate ability to reason about class and module boundaries, extensibility, performance and complexity trade offs, and to produce clean code and APIs that support long term maintenance.

EasyTechnical

18 practiced

Compare composition and inheritance in object-oriented design. Describe at least three situations where composition is clearly preferable to class inheritance, and provide a short pseudo-code sketch showing how you would refactor an inheritance-heavy design into composition.

Sample Answer

Composition and inheritance are both ways to reuse code: inheritance expresses an “is-a” relationship (subclass extends superclass behavior), while composition expresses a “has-a” relationship (object contains other objects and delegates work). Inheritance couples subclasses to a parent’s implementation and can break encapsulation; composition favors encapsulation, clearer boundaries, and runtime flexibility.

Three situations where composition is preferable:- When you need runtime behavior changes (strategy pattern) — composition lets you swap components without changing class hierarchy.- When multiple orthogonal behaviors must be combined (avoid combinatorial explosion of subclasses).- When you want to limit coupling and preserve encapsulation (use interfaces + composed helpers instead of deep inheritance trees).

Refactor sketch (inheritance-heavy -> composition):

Before (inheritance-heavy):

python

class Animal:
    def move(self): pass

class Bird(Animal):
    def move(self): return "fly"

class Fish(Animal):
    def move(self): return "swim"

class Penguin(Bird):
    def move(self): return "swim"  # overrides awkwardly

After (composition using strategy):

python

class MoveBehavior:
    def move(self): pass

class Fly(MoveBehavior):
    def move(self): return "fly"

class Swim(MoveBehavior):
    def move(self): return "swim"

class Animal:
    def __init__(self, move_behavior: MoveBehavior):
        self._move_behavior = move_behavior
    def move(self):
        return self._move_behavior.move()

penguin = Animal(Swim())
sparrow = Animal(Fly())

Key benefits: simpler hierarchy, easier to test and extend, behaviors swapped at runtime, avoids incorrect inherited behavior and fragile base class problems.

EasyTechnical

18 practiced

Explain the Interface Segregation Principle (ISP). Given an interface 'MultifunctionDevice' with methods print(), scan(), fax(), and email(), describe how you'd redesign it if some clients only need printing and others only scanning. Provide interface examples and explain how ISP improves implementer and client code.

Sample Answer

The Interface Segregation Principle (ISP) states that clients should not be forced to depend on methods they do not use. Instead of one large “fat” interface, provide several small, role-specific interfaces so clients and implementers depend only on what they need.

Example: starting (violates ISP)

java

public interface MultifunctionDevice {
    void print(Document d);
    void scan(Document d);
    void fax(Document d);
    void email(Document d);
}

Redesigned (follows ISP)

java

public interface Printer {
    void print(Document d);
}

public interface Scanner {
    void scan(Document d);
}

public interface Fax {
    void fax(Document d);
}

public interface Emailer {
    void email(Document d);
}

// For devices that implement multiple roles:
public interface MultiFunctionDevice extends Printer, Scanner {}

How this improves implementer and client code:- Implementers implement only needed interfaces. A simple network printer implements Printer; it isn’t forced to provide no-op scan/fax methods.- Clients depend only on capabilities they require. A printing-only client takes a Printer, so its code is simpler and has clearer contracts.- Easier testing: mock small interfaces for unit tests.- Better evolution: adding a new capability won’t break unrelated clients.- Composability: complex devices can be built by combining small interfaces.

Trade-offs: more interfaces to manage, but clarity and maintainability outweigh the cost in most designs.

HardSystem Design

22 practiced

Design a language-agnostic server-side API and client SDK strategy for serving machine learning models. Focus on minimal, stable client-facing objects (model, predict request/response), versioned model interfaces, and an extensibility mechanism for custom pre/post processors that does not force breaking changes on SDK consumers.

Sample Answer

Requirements:- Minimal, stable client-facing surface: Model, PredictRequest, PredictResponse.- Language-agnostic transport (JSON/HTTP+gRPC with protobuf).- Versioned model interfaces with backward compatibility.- Extensible custom pre/post processors without forcing SDK changes.

High-level architecture:Client SDKs (thin) ↔ API Gateway (HTTP/gRPC) ↔ Model Router → Model Runtimes (containers) + Processor Registry

Core API design (stable objects):- Model: {id, name, interface_version, metadata}- PredictRequest: {model_id, inputs, parameters?, processor_refs?}- PredictResponse: {model_id, outputs, model_version, diagnostics?}

Versioning:- Interface_version on Model (semantic major.minor).- Server provides /models/{id}/metadata returning supported versions and schema (protobuf/JSON Schema).- SDKs ship with a stable client object that delegates schema validation to server-provided schema at runtime. Major version bumps are required only when breaking changes occur.

Extensibility for processors (no SDK break):1. Processor Registry: processors are independent services registered with the model-serving platform and referenced by stable IDs/URIs.2. PredictRequest.processor_refs: list of {id, config} where id is opaque to SDK. SDK only passes through.3. Server-side orchestration resolves processor IDs, loads appropriate version, runs pre/post processing in the model runtime pipeline.4. Processors communicate via well-defined small contracts (Input/Output blobs). Server enforces compatibility and sandboxing.

Backward-compatibility mechanisms:- Default pipeline: if processor_refs omitted, server uses model's canonical pipeline.- Feature negotiation: client can query /capabilities to see supported optional features.- Graceful ignore: unknown processor IDs produce non-breaking warnings in diagnostics and either default behavior or error, configurable per-client.

Security & Ops:- Signed processor bundles, version pinning, quotas, and observability per-processor.- Use gRPC + protobuf for performance, JSON for browser/quick clients. Server provides generated schemas to auto-generate SDK helpers; SDKs remain thin.

Trade-offs:- Server-managed processors reduce client complexity but centralize trust and ops.- Runtime schema negotiation adds latency but avoids frequent SDK releases.

This approach keeps SDK objects minimal and stable, pushes extension logic server-side via opaque processor references, and uses explicit versioning and schema negotiation to avoid breaking SDK consumers.

HardTechnical

19 practiced

You must choose between making an object graph immutable or using defensive copies in a concurrent system with high write throughput. Compare consistency models, latency, memory/Garbage Collection impact, ease of reasoning, and complexity of implementation. Describe how you would implement each approach and what telemetry you'd collect to make an informed decision.

Sample Answer

Clarify trade-offs first: immutability means each write produces a new object graph (persistent data structures or full copy), guaranteeing readers see a consistent snapshot without locking. Defensive copies mean mutating shared objects but copying on read or write to isolate access.

Consistency models- Immutable: snapshot consistency (readers see a stable version); writers create new versions; easy to reason about linearizability when swaps are atomic (compare-and-swap on root).- Defensive-copy: eventual or read-isolated consistency depending on strategy; risk of observing partial state if copies aren’t applied atomically.

Latency- Immutable: write latency depends on copy cost; with structural sharing (persistent trees) writes can be O(log n) and low-latency. Reads are fast (no locking).- Defensive-copy: reads incur copy cost if copying on read; copying on write shifts cost to writers. Worst-case large object copies increase tail latency.

Memory / GC impact- Immutable: higher allocation rate — many short-lived objects; increases GC pressure and pause times, especially in JVM. Using structural sharing and pooling reduces pressure.- Defensive-copy: also increases allocations if copying frequently; less churn if shallow copies or copy-on-write for small deltas.

Ease of reasoning- Immutable: easiest — no synchronization bugs, data races eliminated for readers.- Defensive-copy: harder — must ensure every access path performs necessary copy; risk of stale references and subtle bugs.

Complexity of implementation- Immutable: moderate if using existing persistent data-structure libraries; harder if converting large mutable graphs to efficient persistent structures.- Defensive-copy: simple conceptually but error-prone; complexity grows ensuring atomic publication and minimizing copies.

How to implement- Immutable: represent root as an atomic reference to a persistent data structure. Writers build a new graph (using structural sharing), then publish via atomic swap. Use versioning/sequence numbers for GC/compaction. Example: Persistent AVL/RB trees or Clojure-style persistent vectors.- Defensive-copy: choose copy-on-write for writers: mutate a thread-local copy then publish with atomic swap; or copy-on-read: readers clone before use. Always publish new root atomically and null out old references for GC.

Telemetry to decide- Allocation rate (objects/sec), object size distribution- GC throughput, pause times, young/old gen promotions- 99th/99.9th percentile latencies for reads and writes- CPU utilization and context-switches- Memory resident set / heap usage over time- Copy frequency and bytes copied per second- Contention metrics (locks, CAS retries)- Error/consistency violation counts during canary tests

Decision approach- Prototype both (small persistent-structure and copy-on-write) behind feature flags; run production-like load tests measuring above telemetry. If write throughput is extremely high and allocations/GC unacceptable, prefer defensive strategies with low-copy deltas or hybrid: immutable for read-mostly parts, defensive-copy or in-place sharded mutability for hot-hot paths.

HardTechnical

32 practiced

You must add a new cross-cutting behavior (audit logging) across many unrelated classes without modifying each class. Evaluate the use of Visitor, Decorator, Proxy, and AOP approaches. For each approach propose an implementation sketch, discuss runtime performance and LSP impacts, and describe how you'd test the added behavior.

Sample Answer

Situation: We need audit-logging (cross-cutting) added to many unrelated classes without editing each class. I'll evaluate Visitor, Decorator, Proxy, and AOP with a sketch, runtime cost, Liskov Substitution Principle (LSP) impact, and testing approach.

Visitor- Sketch: Implement Visitor interface with visit(TypeA), visit(TypeB)... each class accepts(Visitor). Visitor does audit actions.- Runtime: O(1) per visit; minimal overhead but requires double-dispatch.- LSP: Preserves LSP if accept is part of interface; but adding accept modifies classes (violates requirement).- Comments: Not suitable because it requires invasive changes.- Testing: Unit tests for visitor logic; integration tests ensure accept calls happen.

Decorator- Sketch: Wrap objects with AuditDecorator implementing same interface; decorator logs then delegates.- Runtime: Small per-call overhead (function call + logging). Scales with wrappers.- LSP: Good if decorator implements same interface; must preserve behavior/side-effects to maintain LSP.- Comments: Works well when objects are created in one place or can be injected.- Testing: Unit tests for decorator (mock delegate, assert logs); end-to-end to verify decorated instances used.

Proxy- Sketch: Use dynamic proxy (Java InvocationHandler / Python proxy) to intercept method calls and log, return delegate results.- Runtime: Slight reflection/dynamic dispatch overhead; acceptable for many apps, measurable under very high throughput.- LSP: Transparent if proxy implements same interface; must forward exceptions and preserve semantics.- Comments: Non-invasive if you can supply proxies at construction/injection points.- Testing: Mock underlying object, assert handler logs and forwards; contract tests to ensure exact exceptions/results.

AOP (recommended)- Sketch: Define pointcuts on public methods (e.g., @Audit or execution(* com.app..*(..))). Advice logs before/after/around.- Runtime: Low overhead with compile-time or load-time weaving; higher if using proxy-based AOP or heavy reflection.- LSP: Non-invasive, preserves LSP because behavior is orthogonal; must avoid changing method contracts (return values/exceptions).- Comments: Best for broad, non-invasive cross-cutting concerns; centralized, configurable.- Testing: - Unit: test core logic without AOP. - Integration: enable weaving and verify logs fired (use test AOP config). - Contract tests: ensure exceptions/return values unaffected. - Performance tests: benchmark critical paths with and without AOP. - Failure tests: simulate logging failures (e.g., logging backend down) and ensure core behavior unaffected.

Trade-offs & choice- If you control DI/creation points: Proxy or Decorator gives explicit control.- If you need minimal code changes and wide coverage: AOP (weaving) is preferred for maintainability and configurability.- Visitor is least suitable here due to invasiveness.

Practical notes- Ensure logging is async/non-blocking to limit latency impact (buffer, batching).- Preserve exception transparency and idempotency to respect LSP.- Add feature flags/filters so audit can be toggled in prod without code changes.

Unlock Full Question Bank

Get access to hundreds of Object Oriented Design Principles interview questions and detailed answers.

Join thousands of developers preparing for their dream job.