golang-design-patternslisted

# Go Design Patterns Use the smallest pattern that resolves a demonstrated pressure. Go APIs benefit more from explicit ownership and stable contracts than from naming every familiar object-oriented pattern. ## Understand the existing design Before proposing or implementing a pattern: 1. Read repository instructions, `go.mod`, package layout, constructors, public APIs, and tests. 2. Identify the actual pressure: optional configuration, lifecycle ownership, boundary isolation, multiple implementations, unbounded work, or data volume. 3. Record compatibility constraints and real callers. Do not redesign the package around a hypothetical future use. 4. Prefer the repository's established pattern when it already handles the requirement cleanly. 5. Keep review and implementation scope separate, and report broader design opportunities independently from the requested change. ## Construction and configuration | Shape | Use when | Avoid when | | --- | --- | --- | | Direct arguments | Few required values with clear meaning | Several adjacent values are easy to swap or evolve together | | Config struct | Configuration is cohesive, validated together, or loaded externally | It obscures a tiny stable API | | Functional options | A public constructor has genuinely optional, orthogonal settings and compatibility matters | Options hide required dependencies or permit invalid intermediate state | | Builder | Construction is staged and the intermediate choices need validation or fluent