What are the SOLID principles, and why do teams bother with them?

beginner

Re-explain

SOLID is an acronym for five design rules that keep code easy to change, test and reuse.

Single responsibility: a class should have one reason to change.
Open/closed: you can add behaviour without editing code that works.
Liskov substitution: a subtype must work wherever its base type does.
Interface segregation: small contracts beat one fat contract.
Dependency inversion: high-level code should depend on abstractions, not concrete classes.

Teams bother because each letter names a pain they have felt.

Applied blindly, SOLID produces a class per line of logic, which is its own mess.

Rewriting in plainer words…

This answer doesn't lend itself to a diagram - it reads best . No credits were charged.

Why there's no diagram: “”

The interactive diagram is below the answer - jump to diagram ↓ · Below it, the related concept . Jump to it ↓

The diagram below the answer is the concept . Jump to it ↓

Tailored explanation · switch back to · ·

What should the new diagram focus on?

How well did you know this?

AI:

Saved in this browser - sign in to keep your review list.

How should your speech become text?

Listening… your words appear above as you speak - tap Stop when you're done.

Recording · cr - tap Stop & transcribe when you're done.

Transcribing with AI…

Voice:

Keep going - a few more words and AI can grade it.

Interview lens How interviewers actually use this question

Can following one SOLID principle make you break another? Give an example. Name a real tension, like splitting for SRP until one feature touches many small classes, and say how you pick which rule wins.
A method switches over a type code. Which principles does that break, and how would you fix it? Open/closed, since each new type edits the switch, often SRP too. Polymorphism or a strategy map fixes it, unless the set of types never changes.
Walk me through dependency inversion with a concrete example. The high-level class owns an interface such as OrderRepository, the database class implements it, and a test passes in a fake.
In a code review, which smells tell you a SOLID principle is being broken? Map smells to letters, e.g. shotgun surgery, a growing switch, an override that throws, empty stub methods, new() buried in business logic.
When would you choose not to apply SOLID to a piece of code? Throwaway scripts or a class with one implementation and no second in sight. Add the interface when the second case or the pain shows up.

SOLID is five design rules that keep code easy to change, test and reuse, and each letter is named after a pain teams have felt.
Single responsibility means a class has one reason to change. Open/closed means you add behaviour without editing code that already works.
Liskov substitution says a subtype has to work anywhere its base type does, and interface segregation says small contracts beat one fat contract.
Dependency inversion means high-level code depends on abstractions rather than concrete classes, so the logic can run without a real database.
Teams bother because they've hit the pains, like one change spread across five files, an if chain that grows with every feature, or a subclass that throws from an inherited method.
The limit is that applied blindly, SOLID gives you a class per line of logic, so I reach for a letter when I can name the pain it fixes.

Recites the five names and stops The question also asks why teams bother. Tie each letter to the pain it prevents, such as an if chain that grows with every new feature.
Says SRP means a class does one thing The rule is one reason to change. A class with several methods that all change for the same reason is fine, so split by reason to change, not method count.
Treats DIP and dependency injection as one thing DIP is about the direction of dependencies, toward abstractions. Injection is one way to hand those in. Blurring them sounds like you know the tool but not the rule.
Sells SOLID as always good Blind use gives you a class per line of logic. Show judgement by saying when you'd hold back, like a class with one implementation and no second one coming.

Interview lens

Likely follow-ups, what you can say, and the weak answers to avoid.

Want a quick review of the fundamentals? See the Object-Oriented Programming cheatsheet.

Pro · $10/mo

Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.