Question
Which practice avoids a common mistake with Design Patterns and SOLID?
- Do not force a pattern onto simple code when composition and plain objects already communicate the solution clearly.
- Ignore the Design Patterns and SOLID issue and rely on team discipline instead of APIs or contracts.
- Silence the Design Patterns and SOLID problem by using raw types, broad catches, or shared mutable state.
- Prefer the version of Design Patterns and SOLID that makes behavior less predictable as long as the code compiles.
Hint
Look for the option that protects correctness instead of hiding the problem.
Answer and rationale
Correct answer: A. Do not force a pattern onto simple code when composition and plain objects already communicate the solution clearly.
Do not force a pattern onto simple code when composition and plain objects already communicate the solution clearly. This is a common failure mode in real Java code and a frequent interview follow-up.
Track: Java