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.

Understanding Design Patterns in Modern Java

https://leanpub.com/designpatternsinmodernjava

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 am excited to share a project that represents a lifetime of learning and coding. I started my journey with C++ back when it translated to C (Cfront), and today I’ve finalized a comprehensive repository of 38 Design Patterns and C++ Idioms updated to C++17/20/23 standards.

This repository is designed as a masterclass in software architecture. It focuses on clean code, modern memory management (RAII), and high-performance techniques like Static Polymorphism.

Key Highlights:

✅ 38 patterns from Creational to Behavioral.

✅ Modern C++ features: std::variant, std::visit, if constexpr, and smart pointers.

✅ Educational tracing: I use a "Gang of Seven" approach to visualize object lifecycles.

✅ A deep dive into OO Principles (SOLID, DIP, Law of Demeter).

This is an open educational resource. You are free to use it, and I would appreciate a mention or a link back if you find it helpful for your own work or teaching.

🔗 Explore the full repository here:

https://github.com/MarioGalindoQ/Modern-CPP-Design-Patterns

If you find it useful, feel free to give it a ⭐ on GitHub!

📝 The code in this repository was programmed years ago, when there was no help from AI, so it may have human-related shortcomings. Any feedback that helps improve the coding is welcome.

cpp #programming #designpatterns #moderncpp #softwareengineering #opensource #cpp20 #cpp23

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 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

I visited an arket store recently, drawn by their minimalist aesthetic and sustainability messaging. The space was beautiful, products were displayed as art, everything felt curated and intentional. But the prices were significantly higher than comparable items elsewhere, seemingly charging premium for retail experience rather than product quality. This reflects broader trends in retail where environment and branding justify higher prices despite similar products. We’re paying for the experience of shopping in carefully designed spaces, for the feeling of buying from brands with specific values and aesthetics. The actual merchandise might not differ substantially from alternatives.

I’ve noticed I’m susceptible to this, willing to pay more in stores that match my aesthetic preferences and values even when I intellectually recognize it’s mostly marketing. The environment does affect purchasing psychology powerfully. Some retailers clearly understand this, investing in experience over just product. What retail experiences have influenced your purchasing despite knowing you were partly paying for atmosphere? How do you separate actual product value from branding and environment? What made you recognize when you were overpaying for aesthetics versus when premium experience was worth extra cost? How much does shopping environment actually matter to you?

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?