What Is Object Oriented Programming?
Quick note before we start: none of this is Salesforce specific. Everything here applies equally to Java, C#, Python or JavaScript. But it matters enormously in Salesforce, because Apex is an object oriented language and writing it as though it isn’t is how orgs end up unmaintainable.
OOP is basically what it says on the tin. It’s a way of structuring code so that it represents objects: the things they know, and the things they can do.
A Car class knows its colour and its mileage. It can start, stop and accelerate. Data plus behaviour, bundled together in one place.
The alternative, procedural programming, keeps data in one place and functions that operate on it somewhere else. That works fine at small scale and gets increasingly painful as things grow.
The Building Blocks
Class – the blueprint. Describes what something is and does.
Object (or instance) – an actual thing built from that blueprint.
Property (or field) – what the object knows.
Method – what the object can do.
public class Car
{
//Properties - what it knows
private String colour;
private Integer mileage;
//Constructor - how it gets built
public Car(String carColour)
{
this.colour = carColour;
this.mileage = 0;
}
//Methods - what it can do
public void drive(Integer miles)
{
this.mileage += miles;
}
public Integer getMileage()
{
return this.mileage;
}
}
//Two objects, one blueprint, separate state
Car redCar = new Car('Red');
Car blueCar = new Car('Blue');If any of that is unfamiliar, the Apex Master Class covers all of it slowly.
The Four Pillars
Some people call them principles, some call them pillars. Same four things.
1. Encapsulation
Bundle data with the methods that work on it, and restrict direct access to the internals. That second half is the important bit, and it’s what the next episode is entirely about.
In practice: your fields are private, and the outside world goes through methods you control.
2. Abstraction
Hide complexity behind a simple interface. When you call insert myAccount; you have no idea what Salesforce does underneath, and you don’t need to. That’s abstraction.
Your job is to give other developers the same courtesy. A method called calculateCommission() should not require the caller to understand the commission rules.
3. Inheritance
One class extends another and gets its behaviour for free.
public virtual class Vehicle
{
public void startEngine() { System.debug('Vroom'); }
}
public class Car extends Vehicle
{
//startEngine() came along for free
}Remember Apex needs virtual or abstract on the parent before you can extend it, unlike Java where anything is fair game by default.
One caution: inheritance is easy to overuse. A deep hierarchy is hard to follow and easy to break, and it’s very easy to violate the Liskov Substitution Principle without noticing. Composition, where a class simply has another object rather than extending it, is often the better answer.
4. Polymorphism
Literally “many forms.” Different classes can respond to the same method call in their own way.
public virtual class Vehicle
{
public virtual void makeNoise() { System.debug('Some noise'); }
}
public class Car extends Vehicle
{
public override void makeNoise() { System.debug('Vroom'); }
}
public class Bicycle extends Vehicle
{
public override void makeNoise() { System.debug('Ring ring'); }
}
//The caller doesn't know or care which it's holding
for (Vehicle v : vehicles)
{
v.makeNoise();
}That loop is the whole point of OOP in one snippet. Add a Motorcycle class tomorrow and the loop doesn’t change at all.
This is what interfaces give you, and it’s the mechanism most design patterns are built on.
Why It Matters In Salesforce
A very common way to write Apex is one enormous class with a dozen static methods, no state, no structure. It’s basically procedural code wearing a class as a hat.
It works. It also becomes untestable and unchangeable faster than you’d think, for reasons I went through in the Single Responsibility post.
Proper OOP gives you code you can extend without editing, swap out in tests, and hand to somebody else without a two hour explanation. On a platform where orgs live for a decade, that compounds.
What’s Next
Four pillars: encapsulation, abstraction, inheritance, polymorphism.
In the next episode we take encapsulation properly, because the standard definition you’ll find online is technically correct and almost entirely useless.
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
