Why can a Mediator degrade into a 'god object', and how do you keep it from happening?
answer
- Centralization is the feature AND the failure mode
- God object = high coupling, low cohesion, breaks SRP
- Growth is monotonic: rules only get added
- Fix: one mediator per cohesive cluster
- Split via sub-mediators / strategies; cohesion = the split signal
basics
~20 sBecause the mediator collects all the interaction rules in one class, it keeps growing as you add features. Eventually it knows and controls everything — a god object. Prevent it by keeping each mediator small and focused, splitting big ones into smaller mediators.
solid answer
~60 sMediator works by pulling inter-colleague logic out of the colleagues and into one central class. That is exactly why it can rot: every new interaction rule and every new colleague adds more responsibility to the same class, so the mediator monotonically grows. A 'god object' is a class that knows about and controls too much of the system — high coupling, low cohesion, hard to test or change safely. The mediator is structurally prone to this because all coordination is deliberately funneled through it. Defenses: keep one mediator per cohesive cluster rather than one giant mediator for a whole screen or subsystem; split a large mediator into sub-mediators (and let mediators coordinate at a higher level); extract rule groups into collaborating helper objects or strategies; push purely local behavior back into the colleagues; and watch cohesion metrics — if the mediator's methods touch disjoint subsets of colleagues, those are seams to split along. The judgment call is that the centralization is a feature until the central class loses cohesion.
go deeper
Knows the mediator can get too big because all the rules pile into it, and that big single-responsibility-violating classes are bad.
Explains god object in terms of coupling/cohesion/SRP and names the basic fix (keep mediators small / split them).
Identifies the structural reason for monotonic growth and gives concrete mitigations (cohesive scoping, sub-mediators, strategy extraction, pushing local logic back) plus the cohesion signal for when to split.
Sets architectural guidance on centralized mediation vs. event bus/pub-sub and presenter/state-machine alternatives, and bakes cohesion thresholds and seams into team conventions and reviews.
## Recap: why the risk is built in The **Mediator** pattern deliberately moves all the "when X happens, update Y and Z" logic out of the individual objects (**colleagues**) and into a single coordinating object (**the mediator**). That centralization is the benefit — one place to read and change interaction rules — but it is also the seed of the problem: *every* coordination rule, by design, lands in the same class. ## What a 'god object' is A **god object** (a.k.a. god class, blob) is an anti-pattern: a single class that knows about, or controls, a large part of the system. Defining the related terms: - **Coupling**: how many other things a class depends on / is depended on by. A god object has very high coupling. - **Cohesion**: how strongly the things inside a class belong together. A god object has *low* cohesion — it does many unrelated jobs. - **Single Responsibility Principle (SRP)**: a class should have one reason to change. A god object violates SRP badly. Consequences: it is hard to understand, risky to modify (one change can break many features), hard to test (you must set up the whole world), and a merge-conflict magnet because everyone edits the same file. ## Why the mediator slides there Because coordination is funneled through one object, growth is *monotonic*: you rarely remove rules, you keep adding them. A login dialog mediator is fine at 4 widgets; the same class for a 40-field admin form with cross-validation, conditional visibility, and inter-section rules becomes a sprawling switchboard. The very property that made colleagues simple (they offload logic to the mediator) loads the mediator up without bound. ## How to keep it healthy 1. **Scope each mediator to a cohesive cluster.** Don't make one mediator for an entire screen or subsystem; make one per group of widgets/objects that genuinely interact. Independent clusters get independent mediators. 2. **Hierarchical mediators.** Split a big mediator into sub-mediators (e.g. per panel/section); a thin top-level mediator coordinates the sub-mediators. This keeps each class small while preserving centralized coordination at each level. 3. **Extract rule groups.** Pull cohesive sets of rules into helper/collaborator objects or **Strategy** objects the mediator delegates to, rather than inlining every rule as another branch. 4. **Push local behavior back to colleagues.** Logic that concerns only one colleague (e.g. input formatting) belongs in that colleague, not the mediator. Keep the mediator strictly for *cross*-colleague coordination. 5. **Watch cohesion as the signal to split.** If the mediator's methods cleanly partition into groups that each touch a disjoint subset of colleagues, those partitions are natural seams. Low cohesion = time to split. 6. **Prefer a leaner architecture when appropriate.** In UIs, an MVP/MVVM presenter or a state-machine/reducer can play a more disciplined mediator role; for cross-module coordination, an event bus / pub-sub trades centralized control for decentralized routing (different trade-offs, no single god object). ## The judgment Centralization is a feature, not a bug — until the central class loses cohesion. The senior skill is recognizing the inflection point (the class is growing, methods touch disjoint colleague sets, every feature edits it) and refactoring *before* the mediator becomes the system's bottleneck.
- What concrete signal tells you it's time to split a mediator?Falling cohesion: when the mediator's methods partition into groups that each touch a disjoint subset of colleagues, and when nearly every new feature edits this one class. Those disjoint groups are natural seams to extract into sub-mediators or strategy objects.
- When would you choose an event bus / pub-sub over a Mediator?When you want decentralized, many-to-many routing without a single coordinating authority — typically for cross-module or cross-service communication where no one object should own all the rules. You trade Mediator's centralized, easy-to-read control for looser, harder-to-trace flow, avoiding a god object but giving up a single source of coordination truth.
saying these in an interview costs you the question
- Treating any large mediator as 'just how Mediator works' instead of a smell.
- Solving the god object by deleting the mediator and re-coupling colleagues directly.
- Confusing high coupling (god object's problem) with low cohesion — name both.
- Putting single-colleague logic in the mediator and calling it coordination.