Mediator - The Mediator
Mediator is a system design pattern that helps minimize chaotic dependencies between objects by restricting direct communication between them, forcing them to interact through an intermediary object.
Initially, when I was unaware of this concept, I used to write "chaotic" code in both Front-end and Back-end. The components in the system sometimes do not operate independently but interact with each other. This interaction causes many difficulties in debugging and maintenance. Let me give examples one by one for easier visualization.
First, on the server side, coupled with microservice architecture, the system has many components operating within a specific scope. Suppose you have three service blocks, A, B, and C, communicating with each other via HTTP. A needs B, so A calls B. A needs C, so A calls C. Similarly, B calls C... But this is just an example with three blocks. If you have six, nine, twelve... such blocks, the overlapping communication would become unimaginable. Therefore, to make coordination easier, we should create a mediator called M. Communication calls must go through M, enabling M to coordinate and log operations, making the debugging process easier later.
On the interface side, where you have multiple buttons, text input fields, alert dialog boxes... If the application is simple, this isn't an issue because one-to-one interactions don't pose many challenges; in fact, they can even speed up coding. However, once the buttons increase, input fields multiply, and the logic between them becomes more complicated, one-to-one interactions become inefficient. Instead, try applying the Mediator design pattern to coordinate them.
One place where I successfully applied this pattern is in the OpenNotas application, where many components interact with each other. Rather than allowing them to interact directly, they must communicate through a mediator. Readers can refer to the source code at tonghoai/opennotas.
References: