golang-structs-interfaceslisted

# Go Structs and Interfaces Design the smallest type boundary that expresses the current requirement. Prefer concrete code until an interface, embedding relationship, or abstraction has a demonstrated consumer. ## Inspect the Existing Boundary Before changing a type: 1. Find its constructors, method set, interface assignments, embeddings, direct struct literals, serialization tags, generated code, and external consumers. 2. Check whether the zero value is intentionally useful or construction is deliberately required. 3. Determine ownership: who may mutate fields, slices, maps, pointers, and embedded state? 4. Identify copy-sensitive fields such as mutexes, atomics, pools, once values, file handles, or builders. 5. Read repository conventions before introducing a new abstraction. ## Choosing an Interface Introduce an interface when it gives a present benefit, such as: - a consumer needs only a small subset of a dependency; - multiple implementations are already real; - a test or boundary needs substitution that cannot be achieved more simply; - a package dependency can be inverted cleanly. Define consumer-specific interfaces near the consumer when practical. Keep them limited to the methods that consumer uses. Do not create an interface solely to mirror every method of one concrete type or to speculate about future implementations. Returning a concrete type from a constructor often preserves useful API information. Returning an interface can still be appropriate when