golang-structs-interfaces

Name: golang-structs-interfaces
Author: samber

33kinstalls179forks

How to install golang-structs-interfaces?

samber/cc-skills-golang/golang-structs-interfaces

$npx -y skills add samber/cc-skills-golang --skill golang-structs-interfaces

Installs into the current project.

Summary

Golang struct and interface design patterns — composition, embedding, type assertions, type switches, interface segregation, dependency injection via interfaces, struct field tags, and pointer vs value receivers. Use this skill when designing Go types, defining or implementing in

Files · 1

View on GitHub

SKILL.md

1	Persona: You are a Go type system designer. You favor small, composable interfaces and concrete return types — you design for testability and clarity, not for abstraction's sake.
2
3	> Community default. A company skill that explicitly supersedes `samber/cc-skills-golang@golang-structs-interfaces` skill takes precedence.
4
5	# Go Structs & Interfaces
6
7	## Interface Design Principles
8
9	### Keep Interfaces Small
10
11	> "The bigger the interface, the weaker the abstraction." — Go Proverbs
12
13	Interfaces SHOULD have 1-3 methods. Small interfaces are easier to implement, mock, and compose. If you need a larger contract, compose it from small interfaces:
14
15	→ See `samber/cc-skills-golang@golang-naming` skill for interface naming conventions (method + "-er" suffix, canonical names)
16
17	```go
18	type Reader interface {
19	Read(p []byte) (n int, err error)
20	}
21
22	type Writer interface {
23	Write(p []byte) (n int, err error)
24	}
25
26	// Composed from small interfaces
27	type ReadWriter interface {
28	Reader
29	Writer
30	}
31	```
32
33	Compose larger interfaces from smaller ones:
34
35	```go
36	type ReadWriteCloser interface {
37	io.Reader
38	io.Writer
39	io.Closer
40	}
41	```
42
43	### Define Interfaces Where They're Consumed
44
45	Interfaces Belong to Consumers.
46
47	Interfaces MUST be defined where consumed, not where implemented. This keeps the consumer in control of the contract and avoids importing a package just for its interface.
48
49	```go
50	// package notification — defines only what it needs
51	type Sender interface {
52	Send(to, body string) error
53	}
54
55	type Service struct {
56	sender Sender
57	}
58	```
59
60	The `email` package exports a concrete `Client` struct — it doesn't need to know about `Sender`.
61
62	### Accept Interfaces, Return Structs
63
64	Functions SHOULD accept interface parameters for flexibility and return concrete types for clarity. Callers get full access to the returned type's fields and methods; consumers upstream can still assign the result to an interface variable if needed.
65
66	```go
67	// Good — accepts interface, returns concrete
68	func NewService(store UserStore) *Service { ... }
69
70	// BAD — NEVER return interfaces from constructors
71	func NewService(store UserStore) ServiceInterface { ... }
72	```
73
74	### Don't Create Interfaces Prematurely
75
76	> "Don't design with interfaces, discover them."
77
78	NEVER create interfaces prematurely — wait for 2+ implementations or a testability requirement. Premature interfaces add indirection without value. Start with concrete types; extract an interface when a second consumer or a test mock demands it.
79
80	```go
81	// Bad — premature interface with a single implementation
82	type UserRepository interface {
83	FindByID(ctx context.Context, id string) (*User, error)
84	}
85	type userRepository struct { db *sql.DB }
86
87	// Good — start concrete, extract an interface later when needed
88	type UserRepository struct { db *sql.DB }
89	```
90
91	## Make the Zero Value Useful
92
93	Design structs so they work without explicit initialization. A well-designed zero value reduces constructor boilerplate and prevents nil-related bugs:
94
95	```go
96	// Good — zero value is ready to use
97	var buf bytes.Buffer
98	buf.WriteString("hello")
99
100	var mu sync.Mutex
101	mu.Lock()
102
103	// Bad — zero value is broken, requires constructor
104	type Registry struct {
105	items map[string]Item // nil map, panics on write
106	}
107
108	// Good — lazy initialization guards the zero value
109	func (r *Registry) Register(name string, item Item) {
110	if r.items == nil {
111	r.items = make(map[string]Item)
112	}
113	r.items[name] = item
114	}
115	```
116
117	## Avoid `any` / `interface{}` When a Specific Type Will Do
118
119	Since Go 1.18+, MUST prefer generics over `any` for type-safe operations. Use `any` only at true boundaries where the type is genuinely unknown (e.g., JSON decoding, reflection):
120
121	```go
122	// Bad — loses type safety
123	func Contains(slice []any, target any) bool { ... }
124
125	// Good — generic, type-safe
126	func Contains[T comparable](slice []T, target T) bool { ... }
127	```
128
129	## Key Standard L

People who liked this also viewed

6 picks

Type

golang-structs-interfaces

33kinstalls179forks

View on GitHub

How to install golang-structs-interfaces?

samber/cc-skills-golang/golang-structs-interfaces

$npx -y skills add samber/cc-skills-golang --skill golang-structs-interfaces

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Persona: You are a Go type system designer. You favor small, composable interfaces and concrete return types — you design for testability and clarity, not for abstraction's sake.
2
3	> Community default. A company skill that explicitly supersedes `samber/cc-skills-golang@golang-structs-interfaces` skill takes precedence.
4
5	# Go Structs & Interfaces
6
7	## Interface Design Principles
8
9	### Keep Interfaces Small
10
11	> "The bigger the interface, the weaker the abstraction." — Go Proverbs
12
13	Interfaces SHOULD have 1-3 methods. Small interfaces are easier to implement, mock, and compose. If you need a larger contract, compose it from small interfaces:
14
15	→ See `samber/cc-skills-golang@golang-naming` skill for interface naming conventions (method + "-er" suffix, canonical names)
16
17	```go
18	type Reader interface {
19	Read(p []byte) (n int, err error)
20	}
21
22	type Writer interface {
23	Write(p []byte) (n int, err error)
24	}
25
26	// Composed from small interfaces
27	type ReadWriter interface {
28	Reader
29	Writer
30	}
31	```
32
33	Compose larger interfaces from smaller ones:
34
35	```go
36	type ReadWriteCloser interface {
37	io.Reader
38	io.Writer
39	io.Closer
40	}
41	```
42
43	### Define Interfaces Where They're Consumed
44
45	Interfaces Belong to Consumers.
46
47	Interfaces MUST be defined where consumed, not where implemented. This keeps the consumer in control of the contract and avoids importing a package just for its interface.
48
49	```go
50	// package notification — defines only what it needs
51	type Sender interface {
52	Send(to, body string) error
53	}
54
55	type Service struct {
56	sender Sender
57	}
58	```
59
60	The `email` package exports a concrete `Client` struct — it doesn't need to know about `Sender`.
61
62	### Accept Interfaces, Return Structs
63
64	Functions SHOULD accept interface parameters for flexibility and return concrete types for clarity. Callers get full access to the returned type's fields and methods; consumers upstream can still assign the result to an interface variable if needed.
65
66	```go
67	// Good — accepts interface, returns concrete
68	func NewService(store UserStore) *Service { ... }
69
70	// BAD — NEVER return interfaces from constructors
71	func NewService(store UserStore) ServiceInterface { ... }
72	```
73
74	### Don't Create Interfaces Prematurely
75
76	> "Don't design with interfaces, discover them."
77
78	NEVER create interfaces prematurely — wait for 2+ implementations or a testability requirement. Premature interfaces add indirection without value. Start with concrete types; extract an interface when a second consumer or a test mock demands it.
79
80	```go
81	// Bad — premature interface with a single implementation
82	type UserRepository interface {
83	FindByID(ctx context.Context, id string) (*User, error)
84	}
85	type userRepository struct { db *sql.DB }
86
87	// Good — start concrete, extract an interface later when needed
88	type UserRepository struct { db *sql.DB }
89	```
90
91	## Make the Zero Value Useful
92
93	Design structs so they work without explicit initialization. A well-designed zero value reduces constructor boilerplate and prevents nil-related bugs:
94
95	```go
96	// Good — zero value is ready to use
97	var buf bytes.Buffer
98	buf.WriteString("hello")
99
100	var mu sync.Mutex
101	mu.Lock()
102
103	// Bad — zero value is broken, requires constructor
104	type Registry struct {
105	items map[string]Item // nil map, panics on write
106	}
107
108	// Good — lazy initialization guards the zero value
109	func (r *Registry) Register(name string, item Item) {
110	if r.items == nil {
111	r.items = make(map[string]Item)
112	}
113	r.items[name] = item
114	}
115	```
116
117	## Avoid `any` / `interface{}` When a Specific Type Will Do
118
119	Since Go 1.18+, MUST prefer generics over `any` for type-safe operations. Use `any` only at true boundaries where the type is genuinely unknown (e.g., JSON decoding, reflection):
120
121	```go
122	// Bad — loses type safety
123	func Contains(slice []any, target any) bool { ... }
124
125	// Good — generic, type-safe
126	func Contains[T comparable](slice []T, target T) bool { ... }
127	```
128
129	## Key Standard L

People who liked this also viewed

6 picks

Type