Single Responsibility: a class should have one reason to change - one responsibility. Mixing concerns (e.g., business logic and persistence) makes a class fragile and hard to modify safely.
2 / 5
The Open/Closed Principle states software should be open for extension but closed for what?
Open/Closed: you should be able to add new behavior by extending (e.g., new subclasses or strategies) without changing existing, tested code, reducing the risk of regressions.
3 / 5
What does the Liskov Substitution Principle require?
Liskov Substitution: a subclass must honor the contract of its parent - same expected behavior, no strengthened preconditions or weakened postconditions - so callers cannot tell the difference.
4 / 5
The Interface Segregation Principle advises what?
Interface Segregation: no client should be forced to depend on methods it does not use. Splitting bloated interfaces into focused ones reduces coupling and unnecessary recompilation.
5 / 5
The Dependency Inversion Principle says high-level modules should depend on what?
Dependency Inversion: both high-level and low-level modules should depend on abstractions. This decouples policy from detail and is enabled in practice by dependency injection.