I. Bridge — Structural Pattern

The Bridge pattern is a structural design pattern that decouples an abstraction from its implementation so that the two can vary independently. This is the definition straight from the Gang of Four — and it's worth unpacking.

Without Bridge, combining two dimensions of variation leads to a class explosion. Imagine you have 2 computer types and 3 printer types — you'd end up with 2×3 = 6 concrete classes (MacOSCanon, MacOSEpson, WindowsCanon, ...). Add a new printer, and you need 2 more classes. Add a new computer, and you need 3 more.

Bridge solves this by splitting the two hierarchies and connecting them via composition ("has-a") instead of inheritance ("is-a"):

• Abstraction — the high-level control layer (e.g. Computer)

• Implementation — the low-level operations layer (e.g. Printer)

• Bridge — the abstraction holds a reference to the implementation interface

Result: M + N classes instead of M × N.

II. Real-world Example

A printing management system:

1. We have two types of computers: MacOS and Window

2. We have two types of printers: HP and Epson

3. Any computer should be able to print with any printer — without hardcoding the combination

4. Computer holds a Printer reference and delegates the actual printing to it

5. Swapping printers at runtime is as simple as calling SetPrinter()

III. Implementation

printer.go — the implementation interface

1package bridge
2
3type Printer interface {
4	Print() error
5}

hp.go — concrete implementation

1package bridge
2
3import "fmt"
4
5type HP struct{}
6
7func (p *HP) Print() error {
8	fmt.Println("HP printer printing...")
9	return nil
10}

epson.go — concrete implementation

1package bridge
2
3import "fmt"
4
5type Epson struct{}
6
7func (p *Epson) Print() error {
8	fmt.Println("Epson printer printing...")
9	return nil
10}

computer.go — the abstraction interface

1package bridge
2
3type Computer interface {
4	Print() error
5	SetPrinter(printer Printer)
6}

macos.go — concrete abstraction

1package bridge
2
3import "fmt"
4
5type MacOS struct {
6	printer Printer
7}
8
9func (m *MacOS) Print() error {
10	fmt.Println("MacOS printing...")
11	return m.printer.Print()
12}
13
14func (m *MacOS) SetPrinter(printer Printer) {
15	m.printer = printer
16}

window.go — concrete abstraction

1package bridge
2
3import "fmt"
4
5type Window struct {
6	printer Printer
7}
8
9func (w *Window) Print() error {
10	fmt.Println("Window printing...")
11	return w.printer.Print()
12}
13
14func (w *Window) SetPrinter(printer Printer) {
15	w.printer = printer
16}

IV. Explain the example above

Let's walk through a concrete usage:

1window := &bridge.Window{}
2macOS  := &bridge.MacOS{}
3epson  := &bridge.Epson{}
4hp     := &bridge.HP{}
5
6window.SetPrinter(epson)
7window.Print()
8
9macOS.SetPrinter(hp)
10macOS.Print()

Output:

1Window printing...
2Epson printer printing...
3MacOS printing...
4HP printer printing...

Step by step:

1. window.SetPrinter(epson) — the bridge is established: Window now holds a reference to Epson

2. window.Print() — Window logs its own message, then delegates to epson.Print()

3. epson.Print() — Epson logs "Epson printer printing..."

4. Same flow for macOS + hp: MacOS logs its message, delegates to hp.Print()

The key insight: neither Window nor MacOS knows anything about HP or Epson concretely — they only know the Printer interface. You can swap printers at runtime without touching the computer code:

1// switch MacOS from HP to Epson at runtime
2macOS.SetPrinter(epson)
3macOS.Print()
4// MacOS printing...
5// Epson printer printing...

Adding a new printer (e.g. Canon) only requires implementing the Printer interface — no changes to MacOS or Window. Adding a new computer (e.g. Linux) only requires implementing the Computer interface — no changes to HP or Epson.

V. Conclusion

The Bridge pattern is powerful when you have two independent dimensions of variation that would otherwise multiply into a large class hierarchy. By connecting them through composition rather than inheritance, both sides stay open for extension without affecting each other.

Trade-offs to keep in mind:

• Good fit: multiple abstraction types × multiple implementation types; need to swap implementations at runtime; want to follow the Open/Closed Principle across both hierarchies

• Poor fit: only one abstraction type or one implementation type — the indirection adds complexity without benefit; simpler problems don't warrant the pattern

No pattern is universally superior. Use Bridge when the class explosion problem is real, not just theoretical.

VI. References

• Go Design Patterns — Mario Castro Contreras

• Source code on GitHub