Senior · Architecture and systems

Patterns with a cost

Which design patterns translate naturally into Go?

Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.

Reveal a strong answer
  1. Composition, small interfaces and functions often implement strategy, adapter and decorator without an inheritance hierarchy. A function can express a policy; an io.Reader wrapper can add counting or limits around another reader.

  2. Functional options can manage optional constructor settings, but required dependencies should remain obvious. A singleton that silently owns a database client hides lifetime and makes parallel tests harder; explicit construction is often clearer.

  3. Use a pattern to solve an identified pressure. Explain the extra indirection, configuration ordering and error behavior. Prefer a direct implementation until two variations or a meaningful boundary justify abstraction.

Common trap

Every pattern having a textbook class diagram does not mean the Go implementation needs the same classes.

Try it

Add metrics around an existing Store without changing every caller or leaking credentials.

Worked solution

Wrap the consumed Store interface, time each operation, classify low-cardinality outcomes and forward context/results unchanged. Decide which layer owns retries and logs to avoid duplicate accounting.

Change the constraint

When does a decorator change semantics, for example by adding retries to a write?

How did you do?

Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.

Not marked. Progress stays on this browser, separate from course completion.

Primary references

Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.