The One Nobody Uses
protected is the access modifier most Salesforce developers have never deliberately typed. It sits in an odd middle ground and it only makes sense once you understand inheritance, which we haven’t formally covered yet.
So here’s the definition, and then we’ll unpack it:
Protected means this class and any class that extends it can use it. Nobody else.
It’s stricter than public (which is anything in your namespace) but looser than private (which is this class only).
A Two Minute Detour On Inheritance
To make sense of protected you need the basic idea of inheritance. One class can extend another and get all its stuff for free.
public virtual class Vehicle
{
protected Integer numberOfWheels;
public void describe()
{
System.debug('I have ' + numberOfWheels + ' wheels');
}
}
public class Motorcycle extends Vehicle
{
public Motorcycle()
{
//We can touch numberOfWheels because it's protected
numberOfWheels = 2;
}
}Motorcycle extends Vehicle, so it inherits describe() and can reach numberOfWheels.
Note the virtual keyword on the parent. In Apex a class can’t be extended unless it’s explicitly marked virtual or abstract. Java lets you extend anything by default; Apex makes you opt in. Slightly annoying at first, arguably safer.
Now, if numberOfWheels had been private, Motorcycle couldn’t touch it at all, even though it’s a subclass. If it had been public, any random class in the org could set it, which nobody wants. Protected is the middle: family only.
Where You’ll Actually See It
The place you’re most likely to meet protected in real Salesforce code is a trigger framework.
The pattern goes like this: a base TriggerHandler class defines empty virtual methods for each trigger context, and your object specific handlers extend it and override the ones they care about.
public virtual class TriggerHandler
{
//Subclasses need these. Nothing else should.
protected List<SObject> newRecords;
protected Map<Id, SObject> oldRecordMap;
protected virtual void beforeInsert() {}
protected virtual void afterUpdate() {}
//The only thing the outside world calls
public void run()
{
if (Trigger.isBefore && Trigger.isInsert)
{
beforeInsert();
}
//...and so on
}
}
public class CaseTriggerHandler extends TriggerHandler
{
protected override void beforeInsert()
{
//Case specific logic here
}
}That’s protected doing exactly what it’s for. Subclasses get everything they need. The rest of the org sees one method, run(), and can’t accidentally call beforeInsert() out of context.
You’ll also see it a lot in the Apex Common Library, which leans heavily on base classes.
Two Rules Worth Knowing
1. You can’t mark a class protected. It only applies to methods, variables and inner classes. A top level class is public or global, full stop.
2. You can widen access when overriding, but not narrow it. Override a protected method as public and Apex is fine with it. Try to override a public method as protected and it won’t compile.
So Should You Use It?
Honestly? Only when you’re deliberately designing a class to be extended.
If you’re writing a normal service class that nothing inherits from, protected buys you nothing over private. Don’t sprinkle it around because it sounds safer.
But if you’re building a base class other developers will extend, a trigger framework, an abstract service, a template of some kind, protected is exactly the tool you want. It lets you share the machinery with subclasses while keeping it out of everybody else’s reach.
What’s Next
Protected: this class plus its subclasses, methods and variables only, mostly useful when you’re designing something to be extended.
We cover inheritance properly later, and my Design Patterns series has a full episode on it if you want to go deeper now.
In the next episode we finish access modifiers with private, which should be your default for basically everything.
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
