SOLID Principles
The five principles Robert Martin grouped under the SOLID acronym, each with the smell that signals a violation and the refactoring that fixes it. Expect to be asked not just to recite them but to spot which one a piece of ugly code is breaking.
part ofSoftware design & architectureoverview, primer and where to startread it →on this pageshowhide
explore
- Single Responsibility Principle5 questions
- Open/Closed Principle6 questions
- Liskov Substitution Principle6 questions
- Interface Segregation Principle6 questions
- Dependency Inversion Principle6 questions
- Applying SOLID6 questions
questions
page 2 of 2The Dependency Inversion Principle is not free. What criterion decides which dependencies are worth inverting, and where does over-applying it hurt an architecture?
basics
~20 sInvert where the dependency is volatile — external systems, vendors, frameworks, anything likely to change or vary. Leave stable things (value types, standard library, pure functions) alone. Too many abstractions add indirection, lowest-common-denominator interfaces, and runtime-only failures without buying substitutability.
How does the Interface Segregation Principle apply at a remote/service API boundary rather than inside one codebase, and what are the failure modes of over-segregating there?
basics
~20 sThe same idea scales up: don't force every consumer onto one giant shared API. Give each consumer group a contract shaped to its needs. But splitting too far gives chatty calls, many contracts to version, and heavy operational overhead — the fix costs more than the fat interface at some point.
Beyond class hierarchies, how does the Liskov Substitution Principle apply to service APIs, message schemas, and plugin implementations — and how would you enforce substitutability across teams?
basics
~20 sAny time a consumer written against one contract receives a different implementation or version, LSP applies: a new version must not demand more of callers or promise less. Enforce it with shared contract tests run in every provider's pipeline.
How does the Open/Closed Principle apply above the class level — to modules, services, and published APIs — and what mechanisms enforce it at that scale?
basics
~20 sAt large scale, being "closed" means other teams and consumers can add capabilities without you changing or redeploying your code: stable published contracts, plug-in boundaries, event streams anyone can subscribe to, and backward-compatible schema evolution.
How do the SOLID principles translate from classes to module, service, and API boundaries - and where do they stop being useful guidance?
basics
~20 sThe same ideas scale up: one owner per service (SRP), plugins and versioned APIs instead of edits (OCP), backward-compatible drop-in implementations (LSP), consumer-specific APIs (ISP), and core logic depending on interfaces the adapters implement (DIP). They say nothing about concurrency, data layout, or failure handling.
showing 31–35 of 35