Build fluency in the vocabulary of a single class that has grown to control far more than it should.
0 / 5 completed
1 / 5
At standup, a dev mentions a single class that has grown to know about and control most of the rest of the system, accumulating far more responsibilities, dependencies, and business logic than any one class should reasonably hold. What is this class called?
A god object is exactly this: it is a single class that has grown to know about and control most of the rest of the system, accumulating far more responsibilities, dependencies, and business logic than any one class should reasonably hold, making it a central bottleneck for almost every change. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This one-class-controls-everything pattern is exactly why a god object is considered a serious code smell that makes a system hard to change safely.
2 / 5
During a design review, the team breaks up a god object called ApplicationManager into several smaller, focused classes, each responsible for one part of what ApplicationManager used to control. Which capability does this provide?
Breaking up the god object here provides localized, independently changeable responsibilities, since each smaller class now owns one concern, instead of every change to any part of the system requiring a careful, risky edit to the single class that controlled everything. Keeping every responsibility inside the single ApplicationManager class means an unrelated change to one concern risks breaking every other concern that class also controls. This one-concern-per-class behavior is exactly why breaking up a god object is the standard fix once a single class has accumulated too many unrelated responsibilities.
3 / 5
In a code review, a dev notices a class called ApplicationManager directly handles user authentication, order processing, email notifications, and report generation, all in one place, with virtually every other part of the codebase depending on it. What does this represent?
This is a god object, since ApplicationManager has accumulated far more unrelated responsibilities than any one class should hold, making it a bottleneck that almost every change has to go through. A cache eviction policy is an unrelated concept about discarded cache entries. This one-class-does-everything pattern is exactly the kind of smell a reviewer flags once a class starts touching concerns that have nothing to do with each other.
4 / 5
An incident report shows an unrelated change to email notification formatting accidentally broke order processing in production, because both concerns lived inside the same god object, ApplicationManager, and a small edit rippled across responsibilities that had nothing to do with each other. What practice would prevent this?
Breaking up the god object into smaller, focused classes means a change to one concern, like email notification formatting, can no longer ripple into an unrelated concern like order processing. Continuing to add new responsibilities to the single ApplicationManager god object regardless of how often an unrelated change breaks something else it controls is exactly what caused the outage described in this incident. This break-up-the-god-object approach is the standard fix once a single class is confirmed to hold multiple unrelated concerns that shouldn't affect each other.
5 / 5
During a PR review, a teammate asks why the team spends time breaking up a god object into smaller classes instead of simply being more careful whenever editing the existing all-in-one class. What is the reasoning?
Breaking up the god object makes each concern's blast radius structurally small, so an edit to one class simply cannot reach unrelated concerns, while being more careful when editing the existing all-in-one class still leaves every concern's code physically tangled together, relying on human attention to avoid a ripple effect that the structure itself does nothing to prevent. This is exactly why breaking up a god object is the standard fix, rather than relying on care alone to manage a system that structurally still lets everything touch everything.