Mediator in Go

The Problem

UI components or domain objects often need to react to each other. If every component directly references every other one, dependencies become tangled and small changes ripple across the whole group. The collaboration becomes hard to reason about because there is no single place that describes the conversation.

The Solution

Mediator moves coordination into a dedicated object. In Go, participants hold a mediator interface rather than references to each peer. The mediator receives events from a component, decides how the rest of the group should react, and keeps the coordination rules centralized.

Structure

• Mediator interface: Defines the notification channel components use.
• Concrete mediator: CheckoutCoordinator owns the collaboration rules.
• Colleagues: Payment, shipping, and summary components report state changes to the mediator.
• Client: Wires components to the coordinator during setup.

Implementation

This example coordinates a checkout form. When shipping or payment changes, the mediator recalculates which parts should be enabled and what the summary panel should show.

package main

type CheckoutMediator interface {
	Notify(sender string, event string)
}

package main

import "fmt"

type ShippingForm struct {
	mediator CheckoutMediator
	method   string
}

type PaymentForm struct {
	mediator CheckoutMediator
	method   string
}

type SummaryPanel struct {
	text string
}

type CheckoutCoordinator struct {
	shipping *ShippingForm
	payment  *PaymentForm
	summary  *SummaryPanel
}

func (f *ShippingForm) Select(method string) {
	f.method = method
	f.mediator.Notify("shipping", method)
}

func (f *PaymentForm) Select(method string) {
	f.method = method
	f.mediator.Notify("payment", method)
}

func (c *CheckoutCoordinator) Notify(sender string, event string) {
	c.summary.text = fmt.Sprintf("shipping=%s payment=%s last=%s:%s", c.shipping.method, c.payment.method, sender, event)
}

package main

import "fmt"

func main() {
	fmt.Println("=== Mediator in Go ===")

	summary := &SummaryPanel{}
	coordinator := &CheckoutCoordinator{summary: summary}
	shipping := &ShippingForm{mediator: coordinator}
	payment := &PaymentForm{mediator: coordinator}
	coordinator.shipping = shipping
	coordinator.payment = payment

	shipping.Select("express")
	payment.Select("card")

	fmt.Println(summary.text)
}

Best Practices

• Use Mediator when many peer-to-peer references are making a collaboration hard to follow.
• Keep colleagues dumb about each other. They should only know the mediator contract.
• Do not let the mediator become a god object; split it when several unrelated conversations emerge.
• Keep mediator events explicit and domain-shaped so the coordination is readable.
• If you only need publish/subscribe notifications, Observer may be a better fit than a central coordinator.

When to Use

• Several objects collaborate tightly and direct references create a web of coupling.
• You want one place to own coordination rules for a bounded interaction.
• Participants should stay reusable outside of one particular collaboration group.

When NOT to Use

• Only one object triggers another and the collaboration is already simple.
• A mediator would just centralize trivial method forwarding.
• The coordinator would absorb too many unrelated workflows.