When Should You Even Think About Design Patterns?
I want to start with the last question first, because I think it’s the most important one and almost nobody asks it.
You should not start with design patterns.
If you’re new to writing code, in any language, learning design patterns early does you more harm than good. It deters people. It’s confusing. And worst of all, it convinces you that all of your code is supposed to conform to a pattern.
It isn’t. Most of the code you write will not use a design pattern, and that’s completely fine. Starting here just makes you over-engineer things that didn’t need engineering.
So when is the right time? Roughly when you can comfortably write, read and modify object oriented code without having to think about the syntax. When you’ve felt the pain of a class that grew too big, or an if statement that gained its ninth branch. Design patterns are answers to problems, and they don’t make sense until you’ve had the problems.
If classes, inheritance and interfaces are still fuzzy, go build things for a while first. Come back. It’ll be here.
So What Are They?
A design pattern is a reusable solution to a problem that comes up over and over in software design.
They’re not code you copy. They’re not libraries you install. They’re closer to a recipe: a described approach to a described problem, which you then implement in whatever language you’re in.
The famous ones come from a 1994 book, Design Patterns: Elements of Reusable Object-Oriented Software, by four authors collectively nicknamed the Gang of Four. That book catalogued 23 patterns, and they’re still the backbone of the conversation thirty years later.
The real value isn’t the code, though. It’s the shared vocabulary. When I say “that should be a Strategy pattern,” any developer who knows patterns immediately understands the shape of what I’m proposing. That’s a lot faster than describing it from scratch every time.
The Three Categories
Creational – about how objects get made. Factory, Singleton, Builder.
Structural – about how objects fit together. Adapter, Decorator, Facade.
Behavioural – about how objects communicate. Strategy, Observer, Template Method.
You don’t need to memorise the taxonomy. It’s just a filing system.
The Ones Actually Worth Learning For Salesforce
There are dozens of patterns. You will realistically use a handful. Here’s where I’d spend your time, in order:
1. Strategy. Swap out an algorithm at runtime. This is the fix for the growing if statement, and it’s probably the single most useful pattern on this platform.
2. Factory. Centralise how objects get created. It’s the backbone of the Apex Common Library’s fflib_Application class, and it’s what makes mocking possible.
3. Template Method. A base class defines the steps, subclasses fill in the details. Every trigger framework you’ll ever see is this pattern.
4. Singleton. One instance, shared. Handy for caching within a transaction, and worth knowing mostly so you can spot when it’s being abused.
5. Builder. Construct complicated objects step by step. Genuinely lovely for building test data.
Notice how many of those you’ve already met without anyone calling them patterns. That’s normal. Most experienced developers reinvent half of these before learning their names.
Why Bother In Salesforce Specifically?
Fair challenge. A lot of Salesforce work is triggers and service classes, so is this overkill?
Two reasons it genuinely isn’t.
Salesforce orgs live a long time. Ten year old orgs are normal. Code you write today will be maintained by somebody else for years, and patterns are how you make code that survives that.
You have to test everything. 75% coverage is the deploy gate, and several of these patterns exist specifically to make code testable. That’s not academic here, it’s the difference between shipping and not.
The Warning
Here’s the failure mode, and it is extremely common: somebody learns patterns and immediately applies them to everything.
Now a three line method is an interface, two implementations, a factory and a config file. Nobody can find anything. The code is objectively worse, and it’s worse in a way that feels sophisticated, which makes it hard to argue with.
A pattern that doesn’t solve a problem you actually have is just complexity. If your if statement has two branches and always will, leave it alone.
Learn to recognise the problems first. The patterns are the easy part.
What’s Next
Patterns are built on object oriented fundamentals, so before we get to specific ones we need those solid.
In the next episode we cover what object oriented programming actually is and its four pillars, then work through them one at a time.
If you want the design principles that sit underneath all of this, my SOLID series pairs very well with this one.
See you next time!
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
