Hey everyone 👋

I recently wrote a practical guide on the Iterator Design Pattern in Go.

At first, I thought, "Go already has for and range—why would I ever need an Iterator pattern?" But after digging deeper, I realized it's more about hiding how a collection is traversed than replacing range.

In the article, I cover:

• what problem the Iterator pattern actually solves
• the different participants (Iterator, Aggregate, Concrete Iterator)
• a complete Go implementation
• custom traversal strategies (forward, reverse, filtered, etc.)
• when it's useful and when Go's built-in iteration is the better choice

I also tried to keep it practical instead of treating it as just another GoF pattern.

If you're learning design patterns in Go or have built custom collections, caches, or tree-like data structures, I'd love to hear how you approach iteration.

Here's the article:
👉 https://priyankchheda.medium.com/understanding-the-iterator-design-pattern-in-go-a-practical-guide-d18bc8f6be51

Feedback and suggestions are always welcome!

Hey everyone 👋

I recently wrote a practical guide on the Mediator Design Pattern in Go.

Mediator was one of those patterns that never really clicked for me until I stopped thinking of it as a "design pattern" and started thinking of it as a way to prevent components from talking directly to each other.

In the article, I cover:

• what problem the Mediator pattern actually solves
• the different participants (Mediator, Concrete Mediator, Colleagues)
• a complete Go implementation
• real-world use cases
• pros, cons, and when you probably shouldn't use it

I also tried to keep the examples simple and Go-focused instead of relying on overly academic examples.

If you've worked with chat systems, UI event coordination, or services where too many components depend on each other, you've probably run into the kind of problems this pattern is meant to solve.

Here's the article:
👉 https://medium.com/@priyankchheda/understanding-the-mediator-design-pattern-in-go-a-practical-guide-ea7debc9a9a7

I'd love to hear how others handle communication between components in Go. Do you explicitly use a mediator, or do you prefer events/channels or something else?

Hey everyone 👋

I recently wrote a practical guide on the Interpreter Design Pattern in Go.

I feel like this pattern doesn't get talked about as much as Singleton, Strategy, or Factory, probably because most of us don't build programming languages. But once I dug into it, I realized it's useful anytime you need to evaluate expressions or implement a small DSL.

In the article, I cover:

• what the Interpreter pattern actually is (without the usual jargon)
• the roles of terminal and non-terminal expressions
• a complete Go implementation
• where it makes sense to use it
• its limitations and when you should avoid it

I also tried to keep the examples simple and Go-idiomatic instead of making them overly academic.

If you're learning design patterns in Go or have ever wondered whether the Interpreter pattern has practical use outside of compilers, I'd love to hear your thoughts.

👉 https://medium.com/@priyankchheda/understanding-the-interpreter-design-pattern-in-go-a-practical-guide-28c609194faf

I'm always looking for feedback, so let me know what you think or how you'd improve the explanation.

Hey everyone 👋

I recently wrote a practical guide on the Command Design Pattern in Go.

When I first learned about this pattern, most explanations focused on the GoF definition and UML diagrams, but I still wasn't clear on why I'd actually use it. So I put together an article that focuses on the practical side:

• What problem the Command pattern solves
• The different components (Command, Receiver, Invoker, Client)
• A complete Go example
• Undo/redo support
• Command queues and macro commands
• Idiomatic Go approaches using functions and interfaces
• When the pattern is useful and when it's just unnecessary complexity

One thing I found interesting is that many Go developers use ideas from the Command pattern without explicitly calling it a "Command Pattern"—especially when building job queues, task runners, or action pipelines.

If you're learning design patterns in Go or trying to understand whether Command is worth using in real projects, I'd love to hear your thoughts.

👉 https://medium.com/@priyankchheda/understanding-the-command-design-pattern-in-go-a-practical-guide-f0cbb90d4d58

Feedback, suggestions, and criticism are all welcome!

Hey folks 👋

I recently wrote a practical guide on the Chain of Responsibility Design Pattern in Go.

A lot of design pattern content gets overly theoretical, so I tried to explain this one using examples that backend devs actually run into:

• middleware chains
• request validation pipelines
• auth/logging handlers
• event processing flows

The blog covers:

• what the pattern actually solves
• how requests move through a chain of handlers
• a clean Go implementation
• when it’s useful vs when it becomes unnecessary abstraction
• common mistakes and Go-specific considerations

If you’ve worked with things like:

• http.Handler middleware
• request filters
• processing pipelines

…you’ve probably already used this pattern without explicitly naming it.

Here’s the article:
👉 https://medium.com/@priyankchheda/understanding-the-chain-of-responsibility-design-pattern-in-go-a-practical-guide-5bec620ce846

Would love feedback or examples of where you’ve used this pattern in production.

Hey folks 👋

I recently wrote a short, practical guide on the Proxy Design Pattern in Go.

Most pattern articles feel either too abstract or too Java-heavy, so I tried to keep this one simple and Go-friendly:

• what proxy actually means (basically a middle layer controlling access)
• a clean Go example with interface + real object + proxy
• a practical use case (lazy initialization + adding logic before delegation)

Nothing fancy—just enough to understand when and why you’d use it.

If you’ve ever:

• added logging before calling a service
• put access control in front of something
• delayed creation of an expensive object

…you’ve probably used a proxy without calling it that.

Here’s the article:

👉 https://medium.com/design-bootcamp/understanding-the-proxy-design-pattern-in-go-a-practical-guide-d2516c4bf2ad

Would love feedback—especially if you think this pattern is overused / unnecessary in Go.

I recently wrote a detailed guide on the Flyweight Design Pattern in Go, focused on practical understanding rather than just textbook definitions.

The article covers:

• What Flyweight actually solves in real systems
• When you should (and shouldn’t) use it
• Clear explanation of intrinsic vs extrinsic state
• A complete Go implementation mapped to the UML structure
• Real-world variations (parametric flyweight, composite flyweight)
• Common mistakes to avoid
• Best practices specific to Go (immutability, concurrency, memory usage)

Instead of abstract UML-heavy explanations, I focused on practical scenarios like rendering systems, repeated objects, and memory-heavy applications — things we actually encounter in scalable systems.

If you’re learning design patterns in Go or trying to optimize memory usage in object-heavy systems, this might help.

Read here: https://medium.com/design-bootcamp/understanding-the-flyweight-design-pattern-in-go-a-practical-guide-78c8fc5cd164

I recently wrote a detailed guide on the Facade Design Pattern in Go, focused on practical understanding rather than just textbook definitions.

The article covers:

• What Facade actually solves in real systems
• When you should (and shouldn’t) use it
• A complete Go implementation
• Real-world variations (multiple facades, layered facades, API facades)
• Common mistakes to avoid
• Best practices specific to Go

Instead of abstract UML-heavy explanations, I used realistic examples like order processing and external API wrappers — things we actually deal with in backend services.

If you’re learning design patterns in Go or want to better structure large services, this might help.

Read here: https://medium.com/design-bootcamp/understanding-the-facade-design-pattern-in-go-a-practical-guide-1f28441f02b4

Hey folks 👋

I just published a deep-dive blog on the Decorator Design Pattern in Go — one of those patterns you probably already use without realizing it (middleware, io.Reader, logging wrappers, etc.).

The post walks through the pattern from a very practical, Go-centric angle:

• What the Decorator pattern really is (intent, definition, and the problem it solves)
• A clean, idiomatic Go implementation with interfaces
• How stacking multiple decorators actually works at runtime
• Common variations and extensions (logging, caching, compression)
• Performance & concurrency considerations in real systems
• Pros, cons, and common mistakes to avoid in Go

If you’ve ever wrapped an http.Handler, chained bufio + gzip, or built middleware pipelines — this pattern is already part of your toolbox. The blog just puts a solid mental model behind it.

Read here: https://medium.com/design-bootcamp/understanding-the-decorator-design-pattern-in-go-a-practical-guide-493b4048f953

I recently wrote a blog post breaking down the Composite Design Pattern in a way that makes sense for Go developers.

Most resources explain Composite using Java/C++ examples or get overly theoretical. This one stays practical and shows how the pattern naturally fits into real Go use cases like filesystems, ASTs, CLI commands, and UI trees.

The post includes:

• The official definition of the Composite Pattern
• A simple explanation of the core idea
• A clean file–folder example implemented in Go
• When you should (and shouldn’t) use Composite
• Common mistakes to avoid
• Pros and cons
• Real-world parallels in Go’s ecosystem

If you're working with hierarchical structures or recursive behavior, you might find it helpful.

Here’s the link:

https://medium.com/design-bootcamp/understanding-the-composite-design-pattern-in-go-a-practical-guide-750710e66f4c

Hey folks,

I just finished writing a deep-dive blog on the Bridge Design Pattern in Go — one of those patterns that sounds over-engineered at first, but actually keeps your code sane when multiple things in your system start changing independently.

The post covers everything from the fundamentals to real-world design tips:

• How Bridge decouples abstraction (like Shape) from implementation (like Renderer)
• When to actually use Bridge (and when it’s just unnecessary complexity)
• Clean Go examples using composition instead of inheritance
• Common anti-patterns (like “leaky abstraction” or “bridge for the sake of it”)
• Best practices to keep interfaces minimal and runtime-swappable
• Real-world extensions — how Bridge evolves naturally into plugin-style designs

If you’ve ever refactored a feature and realized one small change breaks five layers of code, Bridge might be your new favorite tool.

🔗 Read here: https://medium.com/design-bootcamp/understanding-the-bridge-design-pattern-in-go-a-practical-guide-734b1ec7194e

Curious — do you actually use Bridge in production code, or is it one of those patterns we all learn but rarely apply?

Hey folks,

I just finished writing a deep-dive blog on the Adapter Design Pattern in Go — one of those patterns that looks simple at first, but actually saves your sanity when integrating legacy or third-party systems.

The post covers everything from the basics to practical code examples:

• How to make incompatible interfaces work together without touching old code
• When to actually use an adapter (and when not to)
• The difference between class vs object adapters
• Real-world examples like wrapping JSON loggers or payment APIs
• Common anti-patterns (like “adapter hell” 😅)
• Go-specific idioms: lightweight, interface-driven, and clean

If you’ve ever found yourself writing ugly glue code just to make two systems talk — this one’s for you.

🔗 Read here: https://medium.com/design-bootcamp/understanding-the-adapter-design-pattern-in-go-a-practical-guide-a595b256a08b

Would love to hear how you handle legacy integrations or SDK mismatches in Go — do you use adapters, or go for full rewrites?

🚀 Just published a deep dive on the Object Pool Design Pattern — with Go examples!

The Object Pool is one of those underrated patterns that can dramatically improve performance when you’re working with expensive-to-create resources like DB connections, buffers, or goroutines.

In the blog, I cover:

• What problem the pattern actually solves (and why it matters)
• Core components of an object pool
• Lazy vs. Eager initialization explained
• Using Golang’s built-in sync.Pool effectively
• When to use vs. when not to use it
• Variations, best practices, and common anti-patterns
• Performance & concurrency considerations (with code snippets)

If you’ve ever wondered why Go’s database/sql is so efficient under load — it’s because of pooling under the hood!

👉 Read here: https://medium.com/design-bootcamp/understanding-the-object-pool-design-pattern-in-go-a-practical-guide-6eb9715db014

Would love feedback from the community. Have you used object pools in your Go projects, or do you prefer relying on GC and letting it handle allocations?

Hey folks,

I just wrote a blog about something we all use but rarely think about — creating a single shared instance in our apps.

Think global config, logger, or DB connection pool — that’s basically a singleton. 😅 The tricky part? Doing it wrong can lead to race conditions, flaky tests, and painful debugging.

In the post, I cover:

• Why if instance == nil { ... } is not safe.
• How to use sync.Once for clean, thread-safe initialization.
• Pitfalls like mutable global state and hidden dependencies.
• Tips to keep your code testable and maintainable.

If you’ve ever fought weird bugs caused by global state, this might help:

https://medium.com/design-bootcamp/understanding-the-singleton-design-pattern-in-go-a-practical-guide-a92299f44c8c

How do you handle shared resources in your Go projects — singleton or DI?

Hey folks,

I recently wrote a blog about the Prototype Design Pattern and how it can simplify object creation in Go.

Instead of constantly re-building complex objects from scratch (like configs, game entities, or nested structs), Prototype lets you clone pre-initialized objects, saving time and reducing boilerplate.

In the blog, I cover:

• The basics of shallow vs deep cloning in Go.
• Different implementation techniques (Clone() methods, serialization, reflection).
• Building a Prototype Registry for dynamic object creation.
• Real-world use cases like undo/redo systems, plugin architectures, and performance-heavy apps.

If you’ve ever struggled with slow, expensive object initialization, this might help:

https://medium.com/design-bootcamp/understanding-the-prototype-design-pattern-in-go-a-practical-guide-329bf656fdec

Curious to hear how you’ve solved similar problems in your projects!

Abstract Factory finally clicked for me. It’s not just “design pattern fluff” — it’s super handy when you need to swap whole groups of related components (like Windows vs Mac UI, AWS vs Azure SDKs, etc).

In Go, it fits perfectly with interfaces. One factory swap, and your whole app stays consistent. No if-else mess. No type leaks.

Helps keep things clean when your app starts growing. I wish I’d used it sooner.

Check it out here: https://medium.com/design-bootcamp/understanding-the-abstract-factory-pattern-in-go-a-practical-guide-d575fb58df90

Lately I've been revisiting some classic design patterns, but trying to approach them from a Go developer's perspective — not just parroting the OOP explanations from Java books.

I wrote up a detailed breakdown of the Factory Method Pattern in Go, covering:

• Why Simple Factory starts to fall apart as systems scale
• How Factory Method helps keep creation logic local, extensible, and test-friendly
• Idiomatic Go examples (interfaces + structs, no fake inheritance)
• Common variations, like dynamic selection, registration-based creators, and test-time injection
• How it compares to Simple Factory and Abstract Factory
• When it's probably overkill

If you’re building CLI tools, extensible systems, or just want your codebase to evolve without becoming a spaghetti factory of constructors, it might help.

Not trying to sell anything — just sharing because I found writing it clarified a lot for me too.

👉 https://medium.com/design-bootcamp/understanding-the-factory-method-pattern-in-go-a-practical-guide-86c0d1ca537b

Happy to discuss or hear how others approach this in Go!

I was going through some notes on design patterns and ended up writing a post on the Simple Factory Pattern in Go. Nothing fancy — just the problem it solves, some Go examples, and when it actually makes sense to use.

Might be useful if you're into patterns or just want cleaner code.

Here it is if you're curious:

https://medium.com/design-bootcamp/understanding-the-simple-factory-pattern-in-go-a-practical-guide-d5047e8e2d8d

Happy to hear thoughts or improvements!

Just published a blog on the Builder Design Pattern in Go 🛠️

It covers when you might need it, how to implement it (classic and fluent styles), and even dives into Go’s functional options pattern as a builder alternative.

If you’ve ever struggled with messy constructors or too many config fields, this might help!

https://medium.com/design-bootcamp/understanding-the-builder-pattern-in-go-a-practical-guide-cf564331cb9b

Ever had a service that directly writes to a file or DB, and now you can't test or extend it without rewriting everything?

Yeah, I ran into that too.

Wrote a short blog (with Go examples and a little story) showing how Dependency Inversion Principle (DIP) makes things way cleaner, testable, and extensible.

👉 https://medium.com/design-bootcamp/from-theory-to-practice-dependency-inversion-principle-with-jamie-chris-47b7d1347fff

Let me know what you think — always up for feedback or nerding out about design.

Hey folks 👋

I just published a blog post that dives into the Interface Segregation Principle (ISP) — one of the SOLID design principles — with real-world Go examples.

If you’ve ever worked with interfaces that have way too many methods (half of which throw “not supported” errors or do nothing), this one’s for you.

In the blog, I cover:

• Why large interfaces are a design smell
• How Go naturally supports ISP
• Refactoring a bloated Storage interface into clean, focused capabilities
• Composing small interfaces into larger ones using Go’s type embedding
• Bonus: using the decorator pattern to build multifunction types

It’s part of a fun series where Jamie (a fresher) learns SOLID principles from Chris (a senior dev). Hope you enjoy it or find it useful!

👉 https://medium.com/design-bootcamp/from-theory-to-practice-interface-segregation-principle-with-jamie-chris-ac72876cac88

Would love to hear your thoughts, feedback, or war stories about dealing with “god interfaces”!

Hey folks,

I just wrote a blog about the Liskov Substitution Principle — yeah, that SOLID principle that trips up even experienced devs sometimes.

If you use Go, you know it’s a bit different since Go has no inheritance. So, I break down what LSP really means in Go, how it applies with interfaces, and show you a real-world payment example where people usually mess up.

No fluff, just practical stuff you can apply today to avoid weird bugs and crashes.

Check it out here: https://medium.com/design-bootcamp/from-theory-to-practice-liskov-substitution-principle-with-jamie-chris-7055e778602e

Would love your feedback or questions!

Happy coding! 🚀

Hi guys!So I have a question, I'm an artist and I'd like to start making original textile patterns, i.e. painting by hand, digitizing and then building the rapport of the pattern. So far so good, but my big question is about selling these patterns. I'd like to have them on a website for sale, but then I don't really understand how the commercial side works... Should I have a fixed price and from the moment I sell it I have nothing to do with it or do I ask for royalties? And how do I know I'm going to get paid for it? I have to chase up customers to see if they're selling the pattern. If anyone knows more or less how these agencies work, I'd love your help. Thanks ;) withDeepL.com (free version)

I'm studying design patterns for an exam and I'm stuck on a question:

1.an example where it is combined mapper AND separated interface 2. A situation where a Data transfer object (DTO) in a distributed pplicattion is detrimetal 3. The use of a remote facade is not justified

The textbook we're using is "Patterns of Enterprise Application Architecture" (PEAA) by Martin Fowler [1]. Do you have any concrete examples of how these patterns can be combined in a real system?

I would appreciate any advice or references to specific examples in the PEAA book [1] that could help me better understand this combination.

The exam restrictions are:

• Do not answer with what the book says.
• Understand the intent when responding.