OOP & Design Patterns - Single Responsibility Principle - One Class, One Reason to Change
What is a common trade-off or limitation when strictly applying the Single Responsibility Principle in a large system?
What is a common trade-off or limitation when strictly applying the Single Responsibility Principle in a large system?
medium🪤 Complexity Trap Q13 of Q15
Step-by-Step Solution
Step 1: Understand SRP effect
SRP encourages splitting responsibilities, which can increase the number of classes.Step 2: Trade-off analysis
More classes improve modularity but can make the system harder to navigate and understand due to fragmentation.Step 3: Evaluate other options
It always reduces code complexity and never increases the number of classes. is false because SRP can increase class count; It forces all classes to be tightly coupled to maintain cohesion. is false because SRP reduces coupling; It eliminates the need for interfaces or abstractions in the system. is false because SRP does not remove the need for abstractions.Final Answer:
Option C -> Option CQuick Check:
More classes can complicate system navigation -> trade-off of SRP.
Quick Trick: SRP trades fewer responsibilities for more classes.
Common Mistakes:
MISTAKES- Believing SRP always simplifies codebase size.
- Confusing coupling with cohesion effects.
- Assuming SRP removes need for design patterns.
Trap Explanation:
PITFALL- Options that claim SRP reduces complexity or coupling incorrectly ignore practical trade-offs; others misunderstand SRP's role in abstraction.
Interviewer Note:
CONTEXT- Tests candidate's awareness of practical limitations and trade-offs of SRP in real systems.
Master "Single Responsibility Principle - One Class, One Reason to Change" in OOP & Design Patterns
Want More Practice?
15+ quiz questions · All difficulty levels · Free
Free Signup - Practice All QuestionsMore OOP & Design Patterns Quizzes