Object-Oriented Design Extensibility and SOLID

What's being tested

Interviewers probe your ability to design code that can evolve safely: adding features, swapping implementations, and fixing bugs without large rewrites. They want to see mastery of extensibility and the SOLID principles applied pragmatically: clean abstractions, low coupling, high cohesion, and tests that make change cheap. At Ramp this matters because engineers must iterate quickly on financial systems while keeping correctness, auditability, and low-risk deploys.

Core knowledge

Single Responsibility Principle (SRP) — each class/module should have one reason to change; use it to split UI, business logic, persistence, and validation concerns into separate units.
Open/Closed Principle (OCP) — design modules to be open for extension, closed for modification; prefer extension points (interfaces, plugin registries) rather than editing core logic for new behavior.
Liskov Substitution Principle (LSP) — derived types must honor base-type contracts (no stronger preconditions, no weaker postconditions); test substitutability with behavioral unit tests.
Interface Segregation Principle (ISP) — prefer many small, role-specific interfaces over a fat interface; avoids forcing clients to depend on unused operations.
Dependency Inversion Principle (DIP) and Dependency Injection — depend on abstractions (`IPaymentProcessor`) not concretions; use constructor injection for predictability and testability.
Composition over inheritance — implement features via composed collaborators and small strategy objects; inheritance easily couples behavior and breaks LSP when used to share mutable state.
Common patterns: Strategy, Adapter, Factory, Decorator, Chain of Responsibility — know when each enables extension without modification and the complexity each adds.
Contract tests & behavioral unit tests — test interfaces/contracts rather than concrete classes; use mocks to assert interactions and shared contract suites to validate substitutability.
Coupling vs cohesion tradeoff — measure coupling by number of external dependencies per module; aim for high cohesion (single responsibility) to minimize blast radius for changes.
Concurrency & thread-safety — mark which collaborators are shared, design immutable value objects for messages, and document synchronization requirements for implementations.
Runtime extensibility considerations — for hot-pluggable modules consider classloader/plugin isolation, versioned interfaces, and memory leak risks from lingering references.
API compatibility & versioning — for public interfaces use semantic versioning and backward-compatible extension techniques (new optional parameters, feature flags) to avoid breaking consumers.

Worked example — "Design an extensible notification system"

Frame quickly: ask supported channels (email/SMS/push), throughput & latency requirements, delivery semantics (at-least-once vs exactly-once), templating needs, and who manages configuration. Skeleton answer pillars: (1) define a small Notifier interface capturing send(Message) and delivery-result semantics; (2) implement concrete channel classes (`EmailNotifier`, `SmsNotifier`) each encapsulating transport, retries, and backoff; (3) separate templating/formatting and message enrichment as composable steps; (4) register implementations via DI or a plugin registry and expose a factory to select by channel. Flag a tradeoff: a very generic Message payload eases new channels but loses compile-time guarantees; a strict typed model improves safety but requires adapter layers for new channels. Close by saying you'd add contract tests for Notifier implementations, integrate metrics and circuit breakers, and design migration plan for introducing new channels safely.

A second angle — "Design a pricing rules engine"

Same SOLID ideas apply but constraints push different choices: rules change frequently and must be authored by non-engineers, so favor data-driven designs and hot-reloadable rules. Use a small core engine exposing a Rule interface and load rules as expression trees or DSL documents; apply Chain of Responsibility to compose rule evaluation. Dependency inversion helps: the engine depends on abstracted `ProductStore` and `UserContext` so rules remain pure and testable. Here OCP is paramount — new promotions should register without touching engine code — while you accept some runtime interpreter overhead in exchange for business agility.

Common pitfalls

Pitfall: Over-abstracting too early — creating dozens of interfaces for hypothetical future cases increases code surface and cognitive load; start with concrete classes and extract interfaces when a second implementation actually appears.

Pitfall: Ignoring substitutability — implementing an interface but violating behavioral assumptions (e.g., throwing on calls the base never throws) breaks consumers; write shared contract tests to catch this.

Pitfall: Omitting operational concerns — designs that ignore failure modes (retries, idempotency, observability) look clean but fail in production; include delivery semantics and metrics in your design discussion.

Connections

Design extensibility and SOLID naturally connect to API design & versioning, modularization strategies (monolith modules vs microservices), and dependency-injection frameworks (`Spring`, `Guice`, `Dagger`) an interviewer may pivot to. They also tie to testing strategies (contract tests, property-based tests) and CI practices that enforce safe refactors.