All Posts
Thoughts on code and poetry.
Prototype Pattern
The Prototype pattern is what you reach for when “just call the constructor again” is too expensive—or too painful to configure repeatedly. Instead of creating new instances from …
Factory Method Pattern
The Factory Method pattern is the one you use when you want to say “give me a transport,” not “new Truck()” or “new Ship()”. It defines an interface for creating objects but lets …
Builder Pattern
The Builder pattern is what you reach for when a constructor has become a small novel of parameters and optional flags. It’s a creational pattern that lets you construct complex …
Abstract Factory Pattern
The Abstract Factory pattern is one of those tools that quietly keeps large systems from turning into a mess of if (platform == ...) checks. It’s a creational pattern that provides …
What Are Design Patterns
Design patterns are one of those topics that sound academic until the day you recognize one in a gnarly codebase and realize, “Oh, this is just a badly implemented …
Dependency Inversion Principle: Depend on What Matters
The Dependency Inversion Principle (DIP) closes out SOLID, and it’s the one that quietly decides how painful your codebase feels as it grows. At its core, DIP says: High-level …
Interface Segregation Principle: Stop Forcing Clients to Care
The Interface Segregation Principle (ISP) is the “I” in SOLID, and it boils down to a simple idea: A client shouldn’t be forced to depend on methods it doesn’t use. In other words, …
Liskov Substitution Principle: Don’t Surprise Your Callers
The Liskov Substitution Principle (LSP) is the quiet backbone of safe inheritance. It’s the “L” in SOLID, and it answers one simple question: If I swap a base class instance with a …
Open-Closed Principle: Extend Without Breaking Things
The Open-Closed Principle (OCP) sits second in SOLID, but it’s usually the one you feel when requirements start shifting under your feet. The idea is captured in a single sentence: …
Single Responsibility Principle: Why One Job Is Enough
There’s a simple sentence that quietly transforms how you write software: A class should have only one reason to change. That’s the Single Responsibility Principle—the “S” in …