How would you refactor a god class into a maintainable design?
Interviewer Expectations for this Question
01
Core Competency
Assesses fundamental understanding of OOP Concepts conventions, runtime behavior, and memory/performance considerations.
02
Evaluation Criteria
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Comprehensive Model Answer
Verified Solution
A god class is large, does many unrelated things, has many dependencies and is touched by most changes. Treat the refactor as a series of safe, behaviour-preserving steps, backed by tests.
- Write characterisation tests around the public API so you have a safety net.
- Identify distinct responsibilities: persistence, business rules, validation, formatting, notifications.
- Extract cohesive groups into collaborator classes behind interfaces, moving one concern at a time and running tests after each move.
- Replace direct construction of collaborators with injected dependencies so they can be faked.
- Introduce a facade if callers should keep a single entry point, then remove dead code.
before: OrderManager (everything)
after: OrderService + Pricing + Repository + Notifier
Work incrementally and commit often; a big-bang rewrite is risky. Watch for hidden state passed between methods, which is the main obstacle to extraction. Measure progress with coupling metrics and cyclomatic complexity, and use the tests, not intuition, to prove behaviour is unchanged.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.