Explain all five SOLID principles with examples.
SOLID is an acronym for five object-oriented design principles introduced by Robert Martin. Each targets a different source of design fragility.
Single Responsibility Principle (SRP): a class should have only one reason to change. If a class handles both business logic and persistence, a change in the database schema forces a change to the business logic class. Split them: one class models the domain, another handles storage. SRP reduces coupling and makes classes easier to test.
Open/Closed Principle (OCP): software entities should be open for extension but closed for modification. Instead of adding if/else branches to an existing class when requirements grow, you extend behavior through new subclasses or strategy objects. A PaymentProcessor that switches on payment type violates OCP; extracting a PaymentStrategy interface and injecting implementations satisfies it.
Liskov Substitution Principle (LSP): subtypes must be substitutable for their base types without altering program correctness. If Square extends Rectangle and overrides setWidth() to also set height (to keep it square), code that relies on Rectangle's behavior -- setting width and height independently -- breaks silently. The fix is often to not use inheritance where the subtype cannot honor the contract of the supertype.
Interface Segregation Principle (ISP): clients should not be forced to depend on interfaces they do not use. A fat interface that includes methods irrelevant to most implementors forces implementors to provide no-op stubs. Split large interfaces into smaller, focused ones. A Worker interface with work() and eat() is problematic for robots that do not eat -- split into Workable and Feedable.
Dependency Inversion Principle (DIP): high-level modules should not depend on low-level modules; both should depend on abstractions. A service class that directly instantiates a DatabaseRepository cannot be tested without a real database. Inject an abstract Repository interface instead -- the service depends on the abstraction, and the concrete implementation is wired in at the composition root. This is the foundation of dependency injection.
Applied together, SOLID principles produce code where each class has a clear purpose, extension points are explicit, contracts are honored, interfaces are minimal, and dependencies flow toward abstractions.
Candidate can define and give an example for 3-4 of the five principles, but confuses LSP and ISP, or cannot explain DIP beyond use interfaces, or gives abstract examples without concrete code scenarios.
Candidate defines all five precisely, gives concrete code-level examples for each, explains what violation looks like (not just what the principle says), and articulates how DIP enables dependency injection.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment