The Mediator pattern is the last pattern in the design pattern series. I’ve never used this mode before, mainly because I haven’t encountered the right scenario. If you have a scenario suitable for using the mediator pattern, the mediator pattern can help you maintain your system better.

UML class diagrams location: www.processon.com/view/link/6…

This article is linked to: github.com/shidawuhen/…

Definition 1.

1.1 The mediator model

The mediator pattern: A mediation object encapsulates a set of object interactions. The mediator makes objects loosely coupled without explicitly referring to each other, and can change their interactions independently.

UML:

1.2 analysis

The definition is a little bit easier for you to understand. A Colleague does not need to perceive each other with the intermediary controlling all interactions.

A Colleague assumes that a Colleague affects another.

Let’s look at UML again. This can be seen in UML

  • Mediators include all colleagues and are the basis on which mediators can control all interactions

  • A Colleague includes mediators, and a Colleague can directly notify mediators, which is the basis for a Colleague not to need to know about other mediators

ConcreteColleague contains all concretecolleagues. ConcreteColleague has mediators, and ConcreteColleague has mediators. The mediator model is still valid.

2. Application scenarios

What are the benefits of using the mediator pattern?

We imagine a scenario in which a Colleague acts as Colleague1, Colleague2, Colleague3, or Colleague4, forming a many-to-many network of colleagues. As Colleague increases, it becomes more difficult to manage. If the Mediator pattern is used, it becomes a one-to-many star structure, all Colleague is only related to Mediator, and the management complexity is reduced.

In real work, I have not encountered network structure, so I have not used the intermediary pattern. A good example, such as registration in GoLand, is to click on Active GoLand /Evaluate for Free to display different UI components.

3. Code implementation

We have a simple example of implementing GoLand activation.

package main

import "fmt"

/** * @author: Jason Pang * @description: Intermediary interface */
type Mediator interface {
  Process(colleague UIColleague)
}

/** * @author: Jason Pang * @description: Real mediator */
type UIMediator struct {
  activate *ActivateColleague
  evaluate *EvaluateColleague
  text     *TextColleague
}

/** * @author: Jason Pang * @description: Receiver u */
func (u *UIMediator) Process(colleague UIColleague) {
  if colleague == u.activate { // If active
    u.evaluate.Show("Trial content hidden")
    u.text.Show("Please enter the activation code.")}else if colleague == u.evaluate { // For trial use
    u.activate.Show("Enable content hiding")
    u.text.Show("Enter and exit the activation time.")}}/** * @author: Jason Pang * @description: Colleague */
type UIColleague interface {
  Action()
}

/** * @author: Jason Pang * @description: Activate UI */
type ActivateColleague struct {
  mediator Mediator
}

/** * @author: Jason Pang * @description: Activates the triggered action * @receiver a */
func (a *ActivateColleague) Action(a) {
  a.mediator.Process(a)
}

/** * @author: Jason Pang * @description: Activate the UI to display content * @receiver * @param text */
func (e *ActivateColleague) Show(text string) {
  fmt.Println(text)
}

/** * @author: Jason Pang * @description: Try UI */
type EvaluateColleague struct {
  mediator Mediator
}

/** * @author: Jason Pang * @description: Trial triggered action * @receiver e */
func (e *EvaluateColleague) Action(a) {
  e.mediator.Process(e)
}

/** * @author: Jason Pang * @description: Try UI display * @receiver * @param text */
func (e *EvaluateColleague) Show(text string) {
  fmt.Println(text)
}

/** * @author: Jason Pang * @description: Copywriting UI */
type TextColleague struct {
  mediator Mediator
}

/** * @author: Jason Pang * @description: Copywriting trigger action * @receiver t */
func (t *TextColleague) Action(a) {
  t.mediator.Process(t)
}

/** * @author: Jason Pang * @description: Copytext display content * @receiver * @param text */
func (t *TextColleague) Show(text string) {
  fmt.Println(text)
}

func main(a) {
  / / initialization
  m := &UIMediator{}

  activate := &ActivateColleague{
    mediator: m,
  }
  evaluate := &EvaluateColleague{
    mediator: m,
  }
  text := &TextColleague{
    mediator: m,
  }

  m.activate = activate
  m.evaluate = evaluate
  m.text = text
  // Click Activate
  fmt.Println("----------------- click activate")
  activate.Action()
  // Click try
  fmt.Println("----------------- click to try it out")
  evaluate.Action()
}

Copy the code

Output:

—————– Click to activate

Trial content Hidden

Please enter the activation code

—————– Click to try

Enable content hiding

Please enter the activation time

As you can see from the code, Mediators have all of the UI. The UI only calls Mediators and does not need to know about other UIs. Mediators handle all operations through Process. To add a new UI, mediators only need to know about it, without making any changes to other UIs. Of course, to prevent mediators from becoming super classes, it is necessary to make a choice according to the actual situation.

conclusion

An intermediary is a gathering and eliminating mode because a Colleague should manage on his or her own, but it would be too costly to understand each other.

If mediators are collected, the overall efficiency will be much higher, but mediators may become god, which will lead to difficult maintenance.

Doesn’t this look like real life. Therefore, there is no fixed solution in the world. The best solution is to solve the problem better. ‘.

The last

If you like my article, you can follow my public account (Programmer Malatang)

My personal blog is shidawuhen.github. IO /

Review of previous articles:

  1. Design patterns

  2. recruitment

  3. thinking

  4. storage

  5. The algorithm series

  6. Reading notes

  7. Small tools

  8. architecture

  9. network

  10. The Go