Design Patterns in Go

Patterns built around real problems — payment retries, stock alerts, ticket workflows, loan validation — not shapes and animals.

Most pattern repos teach you the diagram. This one teaches you when to reach for the pattern, why Go's approach differs from OOP, and what an interviewer actually wants to hear. Every implementation comes with real-world analogues, a before/after contrast, and a Q&A section with the follow-up questions that separate candidates who memorized diagrams from those who understand trade-offs.

---

What makes this different

Typical pattern repo	This repo
Dog implements Animal	Razorpay/Paytm adapters with real SDK mismatches
Copy-paste from Gang of Four	Go-idiomatic rewrites — interfaces over inheritance, sync.Once over private constructors
"Here's the code"	When to use it, when to avoid it, how it composes with other patterns
No tests	Table-driven tests, mock injection, compile-time interface checks
No interview prep	Q&A sections with follow-ups on concurrency, testability, and edge cases

---

Patterns

Creational

Pattern	Domain	Highlight
Singleton	Config / connection pool	sync.Once thread safety, unexported struct, why global state is a trade-off
Factory	Notification channels (Email, SMS, Push)	Fallback chains, per-request vs. pooled construction, Open/Closed principle
Abstract Factory	Database drivers (Postgres, MySQL)	Families of related objects, switching backends without touching callers
Builder	HTTP request construction	Fluent API, deferred validation, why Builder ≠ Factory

Structural

Pattern	Domain	Highlight
Adapter	Payment gateways (Razorpay, Paytm, Stripe)	Unit conversion, async-to-sync bridging, injected sleepFn for testable retries
Decorator	HTTP middleware (auth, logging, metrics)	Composable layers, same interface all the way down, wrapping order matters

Behavioural

Pattern	Domain	Highlight
Observer	Stock price tracker	ObservationHook — conditional subscriptions beyond classic GoF
State	Support ticket lifecycle	setState unexported, sync.RWMutex, terminal states, why not switch
Strategy	Payment transfer modes (IMPS, UPI, NEFT)	Runtime algorithm swap, 10 real-world applications listed
Chain of Responsibility	Loan application validation	BaseValidator embedding, BuildChain helper, early exit vs. full-pass pipeline
Command

---

How each pattern is documented

Every pattern directory follows this structure:

pattern/
├── README.md ← concept, Go vs. OOP comparison, structure, interview Q&A
├── applications.md ← 5–10 real-world scenarios beyond the example
├── main.go ← runnable demo
├── <domain>/ ← implementation packages
└── go.mod

README.md always includes:

• What the pattern is and which GoF family it belongs to
• When to use it and when to avoid it
• A side-by-side comparison with the closest pattern it gets confused with
• A table mapping each struct/interface to its role
• Interview Q&A with the follow-up questions that actually get asked

---

Quick start

Each pattern is a self-contained Go module. Pick any one and run it:

cd behavioural/observer
go run main.go

Run tests for a pattern:

cd structural/adapter
go test ./payment_adapter/... -v

No workspace setup, no shared dependencies, no global install required.

---

Reading order

If you're starting from scratch or preparing for interviews, this order builds concepts progressively:

1. Singleton — understand controlled instantiation
2. Factory → Abstract Factory — object creation families
3. Builder — complex object construction
4. Adapter — interface translation (great before any system design round)
5. Decorator — layered behavior without subclassing
6. Observer — event-driven design and the Observer/Pub-Sub distinction
7. Strategy — algorithm injection and where it beats if/else
8. State — when switch becomes a maintenance problem
9. Chain of Responsibility → Command — request handling pipelines

---

Patterns in progress

• Prototype
• Facade
• Composite
• Iterator
• Mediator
• Template Method

Contributions welcome — see CONTRIBUTING.md.

---

Repository layout

DesignPatternsInGo/
├── creational/
│ ├── singleton/
│ ├── factory/
│ ├── abstract_factory/
│ └── builder/
├── structural/
│ ├── adapter/
│ └── decorator/
└── behavioural/
├── observer/
├── state/
├── strategy/
├── chain_of_responsibility/
└── command/

---

Contributing

Found a bug, want to add a missing pattern, or have a better real-world scenario? See CONTRIBUTING.md for how to get involved.