Design-Patterns on

Lesson 10: Interpreter Pattern — DSLs and parsing

Wed, 22 Oct 2025 12:00:00 +0000

A few years ago I needed to let non-technical users define filtering rules for a data pipeline. The options were: embed Lua, use a YAML config with increasingly awkward syntax, or write a small domain-specific language. I picked the DSL. It took two days in Rust, and the result was a type-safe, sandboxed expression evaluator that couldn’t crash the host program no matter what users typed. Try getting that guarantee with dynamic code execution in Python.

Lesson 9: Entity Component System — Data-oriented design

Sun, 19 Oct 2025 15:30:00 +0000

I spent years thinking about game objects the OOP way. A Player extends Character extends Entity. A Goblin extends Enemy extends Character extends Entity. Then someone asks “what if a goblin can be mind-controlled and act like a player?” and your inheritance hierarchy collapses.

ECS — Entity Component System — is the answer that the game development world converged on, and it’s fundamentally a Rust-shaped idea. Data and behavior are separated. Composition replaces inheritance. Cache-friendly memory layouts replace pointer-chasing object graphs. Rust’s ownership model maps onto ECS so naturally that Bevy — the most popular Rust game engine — is built entirely around it.

Lesson 8: Middleware / Chain of Responsibility — Tower-style

Thu, 16 Oct 2025 07:15:00 +0000

If you’ve built anything with Express, Koa, or ASP.NET, you know middleware. A request comes in, passes through a chain of handlers — logging, auth, rate limiting, CORS — and eventually reaches your application logic. Each handler can modify the request, short-circuit the chain, or pass it along.

The Chain of Responsibility pattern from the GoF book is basically the same thing. The difference is branding.

What makes this pattern interesting in Rust is tower — the crate that defines how middleware works across the entire Rust async ecosystem. Axum, Tonic, Hyper — they all use Tower’s Service trait. Understanding it unlocks the middleware patterns in all of these frameworks.

Lesson 7: Repository Pattern — Abstracting storage

Mon, 13 Oct 2025 13:45:00 +0000

Every backend developer eventually writes the same code: a function that takes a database connection, runs a query, maps the rows to a struct, and returns it. Then you write another one. And another. Pretty soon your business logic is tangled up with SQL strings and connection pool handles, and testing anything requires a running database.

The Repository pattern fixes this. It’s old — Martin Fowler wrote about it in 2002 — but the way Rust implements it is genuinely different from what you’d do in Java or C#. Rust’s trait system, combined with generics and lifetimes, gives you a repository abstraction that’s zero-cost in production and trivially mockable in tests.

Lesson 6: Factory Patterns — When constructors aren't enough

Sat, 11 Oct 2025 10:00:00 +0000

Here’s a hot take: most “Factory pattern” usage in Java and C# exists purely to work around limitations of constructors. Constructors can’t have descriptive names. They can’t return a different subtype. They can’t fail gracefully. So you wrap them in a static method and call it a Factory.

Rust doesn’t have constructors at all. Every struct is constructed directly, and associated functions already do what Factory Method does in OOP. So do you even need the Factory pattern in Rust?

Lesson 5: Decorator Pattern — Wrapping with trait composition

Thu, 09 Oct 2025 16:30:00 +0000

I remember the moment Decorator clicked for me. I was reading the source for Java’s I/O library — BufferedInputStream wrapping FileInputStream wrapping InputStream. Three layers deep, each adding behavior without subclassing. Elegant. Then I tried to write the same thing in Rust and learned that “wrapping a thing while preserving its interface” is a fundamentally different exercise when you don’t have inheritance.

The good news? Rust’s version is often better than the OOP original, because composition is the default and the compiler enforces the contracts.

Lesson 4: Command Pattern — Closures as commands

Tue, 07 Oct 2025 09:20:00 +0000

The Command pattern has always struck me as one of those patterns that’s really just “wrap a function call in an object.” In Java, you create a Command interface with an execute() method, make a class for each command, and pass them around. It takes about 40 lines of boilerplate to do what a lambda does in one.

In Rust, closures are the Command pattern. But when you need undo, history, or serialization, you still need the structured version — and Rust’s ownership model makes the undo/redo part surprisingly elegant.

Lesson 3: Observer Pattern — Channels and callbacks in Rust

Sun, 05 Oct 2025 11:45:00 +0000

The Observer pattern is where Rust’s ownership model gets really opinionated. In C# or Java, Observer is simple — maintain a list of listeners, call a method on each when something happens. But “a list of mutable references to objects that can be called at any time” is basically everything Rust’s borrow checker exists to prevent. So how do you do event-driven programming in Rust? You have more options than you’d think, and some of them are better than what OOP languages offer.

Lesson 2: Strategy Pattern — Trait objects and generics

Fri, 03 Oct 2025 14:15:00 +0000

In my first real Go project, I wrote an interface for a payment processor. Two implementations — Stripe and PayPal. Simple polymorphism. When I tried the same thing in Rust, the compiler hit me with a wall of errors about dyn, Box, object safety, and sized types. It took me a full afternoon to understand what was happening. The Strategy pattern — which is trivial in most OOP languages — forced me to actually understand Rust’s type system. And I came out the other side a better programmer for it.

Lesson 1: Builder Pattern — Typestate builders and compile-time validation

Wed, 01 Oct 2025 08:30:00 +0000

I once spent three days debugging a production outage caused by a builder that silently accepted a missing host field and defaulted to localhost. In Java. The builder compiled fine, the tests passed — because they ran against localhost — and the deployment connected to nothing. That was the day I stopped trusting optional fields in builders.

Rust’s type system lets you make that entire category of bug impossible. Not at runtime. Not with validation methods. At compile time.