What Are The SOLID Principles?
SOLID is a subset of the many, many design principles floating around in software engineering. They’re five principles about how to structure object oriented code so that it doesn’t turn into an unmaintainable swamp eighteen months from now.
They were introduced by Robert C. Martin, better known as Uncle Bob, around the year 2000, and the acronym itself came slightly later from Michael Feathers. If you’ve read Clean Code or Clean Architecture, this is that world.
Here’s the thing though. Almost every explanation of SOLID you’ll find online is written for Java or C# developers building traditional applications, which makes them feel abstract and faintly irrelevant when you spend your days writing triggers. So this series is about SOLID in Salesforce, with real Apex, and JavaScript examples too since you’ll be writing plenty of that in Lightning Web Components.
Why Should A Salesforce Developer Care?
Fair question, and I want to answer it honestly rather than just insisting that Good Design Is Good.
Think back to the ten year old org I described in the very first Apex Master Class episode. The one where a thirty minute change takes four weeks because nobody can work out what the Contact trigger does anymore.
That org didn’t start out like that. Every single thing that made it awful was a reasonable decision at the time. One more if statement. One more field check crammed into the existing method. One more thing bolted onto a class that was already doing five jobs.
SOLID is a set of five rules for spotting those decisions before you make them. That’s genuinely all it is. It’s not academic, and it’s not about being clever. It’s about not building the thing you’ll hate in three years.
There’s also a very Salesforce specific reason: your code has to be tested. Salesforce requires 75% coverage to deploy, and code that ignores these principles is miserable to test. Classes doing six things need enormous setup. Hard coded dependencies can’t be mocked. If you’ve ever spent longer writing a test than the class it covers, that’s usually the design talking, not the test.
The Five, In Plain English
S – Single Responsibility Principle
A class should have one reason to change. If your AccountService queries records, calculates revenue, sends emails and writes to a log, it has four reasons to change and four different people who might want to change it. Split it up.
O – Open/Closed Principle
Code should be open for extension but closed for modification. Adding a new behaviour shouldn’t mean editing a class that already works. Every time you open a working class to add another else if, you risk breaking something that was fine yesterday.
L – Liskov Substitution Principle
If you’ve got a subclass, you should be able to use it anywhere the parent class was expected and nothing should break. The one everybody finds most confusing, and it’s really about not writing subclasses that lie about what they do.
I – Interface Segregation Principle
Don’t force a class to implement methods it doesn’t need. Several small focused interfaces beat one giant one. Nobody wants to write four empty method bodies just to satisfy a contract.
D – Dependency Inversion Principle
Depend on abstractions, not concrete implementations. This is the one that makes your code testable, and honestly it’s the one with the biggest practical payoff in Salesforce.
Before You Panic
Two things worth saying up front, because SOLID has a reputation for making people feel stupid.
1. These are principles, not laws. They’re guidelines that are right the vast majority of the time. There will be occasions where following one rigidly makes your code worse, and in those cases the right answer is to not follow it. Anybody who tells you otherwise has never had to ship anything.
2. You will over-apply them at first. Everyone does. You’ll learn Single Responsibility and immediately split one perfectly good class into eleven tiny ones, and now nobody can find anything. That’s a normal part of learning this stuff. The judgement comes with practice.
The goal is code you can change safely. If a principle isn’t helping with that in a specific case, don’t use it there.
What You Should Know First
This series assumes you’re comfortable with object oriented basics: classes, methods, inheritance and interfaces.
If any of those are shaky, go work through the Apex Master Class first and come back. There’s no rush, and this will make a lot more sense with those foundations in place.
It also pairs extremely well with the Separation of Concerns series. SOLID tells you how to design individual classes; separation of concerns tells you how to organise them into layers. Different altitudes, same goal.
What’s Next
Six episodes: this overview, then one for each principle, with real Apex and JavaScript examples throughout.
We start in the next episode with the Single Responsibility Principle, which is both the easiest to understand and the one most commonly misunderstood. Google it and the first few results will give you a definition I’d argue is flat out wrong, so we’ll sort that out.
See you there!
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
