Suggest an editImprove this articleRefine the answer for “When does Mediator lead to architectural complexity?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)The **Mediator** pattern starts **complicating the architecture** when the amount of interaction and logic handed to it **exceeds a reasonable limit**, that is, when it turns from a coordinator into the **central brain of the system**, on which everything depends. **Key point:** Mediator is useful as long as it remains a "coordinator"; as soon as it becomes the "ruler of all interactions", the architecture loses flexibility and transparency.Shown above the full answer for quick recall.Answer (EN)ImageThe **Mediator** pattern starts **complicating the architecture** when the amount of interaction and logic handed to it **exceeds a reasonable limit**, that is, when it turns from a coordinator into the **central brain of the system**, on which everything depends. --- ### 1. **When the Mediator Manages Too Many Components** If dozens of different objects and events pass through the Mediator, all their dependencies and interaction scenarios accumulate inside it. It stops being a mediator and becomes a **global controller**, where any edit to one module requires changes in the mediator. > *Example:* a GUI form with 15 elements, where the Mediator manages all of them: > fields, buttons, lists, dialogs, hundreds of `if` conditions and branches. --- ### 2. **When Mediator Takes On Business Logic** The mediator should manage **interaction**, not the components' **actual behavior**. If business rules start being implemented through it ("if order status is X, update the stock and notify the user"), it turns into a **monolithic logic layer** that's hard to test and extend. > A sign: the Mediator knows "too much" about the internals of all participants. --- ### 3. **When Every Change Requires Modifying the Mediator** If adding a new component, field, or button forces you to rewrite the Mediator, that means it has become an **architectural bottleneck** and violates the open/closed principle (OCP). > Eventually Mediator becomes a point of fragility: one change breaks several scenarios. --- ### 4. **When Interactions Become Implicit** In systems with large Mediator objects, component behavior becomes "magical", it's hard to understand who notifies whom and why. Tracing the call chain means scrolling through hundreds of lines of the mediator. > This reduces readability and makes debugging exhausting. --- ### 5. **When There Are Too Many Mediators** Large systems often end up with several Mediators (at the UI, domain, and infrastructure levels). If they start depending on each other, the architecture turns into a **layered tangle of mediators**, where logic is duplicated and confused. --- ### **Signs That Mediator Has Become Harmful** - A large class with hundreds of lines and dozens of `if/else` statements. - Dependencies on every component of the system. - Hard to test or add a new interaction. - Components are no longer reusable without their mediator. --- ### **Conclusion** The **Mediator** pattern complicates the architecture when: - it concentrates **too much logic and too many links**, - it starts **violating the SRP and OCP principles**, - and instead of being a *coordinator*, it becomes the *conductor of the entire application*. **Summary:** > Mediator is useful as long as it remains a "coordinator". > As soon as it becomes the "ruler of all interactions", > the architecture loses flexibility and transparency.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.