3 posts tagged with "design patterns"

Design patterns are a helpful way to talk about structure — reusable blueprints for solving common problems in code. They give us a shared vocabulary, and when used well, they make systems more flexible and understandable.

But once you’ve worked with a few of them, you start to notice something: a lot of patterns look suspiciously similar in actual implementation. You’re injecting different behaviors, delegating to different components, maybe wrapping an object to change what it does — but structurally, it’s often the same playbook with different labels.

This post looks at a few well-known patterns — Strategy, State, Adapter, Proxy, Command — and makes the case that most of them reduce to the same fundamental technique: Dependency Injection. And once you add in two key design principles — Open/Closed and Liskov Substitution — you’ll find you can design pattern-like solutions without memorizing any formal templates.

Ever since the Gang of Four released their legendary Design Patterns book in the 90s, "design patterns" have been a cornerstone of how developers talk about software architecture. Over time, though, the term itself has grown fuzzier. When someone mentions a pattern today, they might be referring to:

• The intent behind the pattern: the problem it's trying to solve.
• The implementation: the exact class structure or code to achieve it.

When we talk about “design patterns you should unlearn in Python,” we’re talking about the second kind: the implementation. These patterns still solve real problems. But in Python, the way you solve them often looks nothing like the solutions shown in C++ or Java.

That’s the key idea behind this series. The moral is simple:

Bears learn to climb trees to reach food. But Eagles do not climb, they fly.

In Part 1, we took apart the Builder and Singleton patterns, showing how Python’s features (like default arguments or modules) make many “classic” implementations unnecessary or even counterproductive.

Now, let’s move on to two more patterns: Flyweight and Prototype. Both solve real problems. But as you'll see, Python gives us simpler, more natural ways to solve them.

Search for “design patterns in Python” and you’ll be rewarded with a parade of tutorials showing off how to faithfully re-implement Gang of Four patterns — complete with class diagrams, factory hierarchies, and enough boilerplate to heat a small village. They’ll make you feel like you’re writing “serious” code. Smart. Professional. Enterprise-ready.

But here’s the problem: most of these patterns solve problems Python doesn’t have. They were designed for languages like Java and C++, where you have to jump through hoops just to get basic things done — no first-class functions, no dynamic typing, no modules as namespaces. Of course you’d need a Factory or a Singleton if your language gives you nothing else to work with.

Blindly copying those patterns into Python doesn’t make you clever. It makes your code harder to read, harder to test, and harder to explain to the next poor soul who has to maintain it — possibly you, three months from now.

In this post, we’ll go over a few classic GOF patterns that you should unlearn as a Python developer. For each one, we’ll look at:

1. How it’s usually (and badly) implemented in Python,
2. Why it actually made sense back when people were writing Java in 2001,
3. And what the Pythonic alternative looks like — because yes, there’s almost always a simpler way.

Let’s start with the biggest offender: Creational Patterns — aka, a whole category of solutions to problems Python already solved.