How to Utilize Apex Properties in Salesforce

Why you should use Apex properties

If you’ve been writing code in Salesforce for a while, you know that keeping your classes clean is a constant battle. One of the easiest ways to win that battle is by using Apex properties effectively. When you’re first learning what is Apex, properties might seem like just another piece of syntax, but they’re actually a massive time-saver for keeping your code organized.

So, what are they exactly? Think of them as a shortcut. Instead of writing separate getter and setter methods for every single variable, Apex properties let you bundle that logic together. It’s a way to control how other parts of your code read or change your data without making things messy. Honestly, once you get used to them, going back to old-school Java-style getters and setters feels like a chore.

A basic example of a property

Here’s the simplest version. It’s a public property that lets anyone read or write to it. You’ve probably seen this a thousand times in controllers or helper classes.

public class ContactDetail {
    public String contactName { get; set; }
}

That little { get; set; } block does all the heavy lifting. You don’t need to declare a private variable and then write two methods to access it. Apex handles that behind the scenes for you. It’s clean, it’s fast, and it’s easy to read.

Common types of Apex properties

Now, here is where it gets interesting. You don’t always want everyone to have full access to your variables. Sometimes you want to lock things down. I’ve seen teams get into trouble by leaving everything wide open, which leads to bugs that are a nightmare to track down. Using specific types of Apex properties can prevent that.

Read-only properties

These are great when you want to show a value but don’t want anyone touching it. You just include the get and leave out the set. In my experience, this is perfect for things like calculated fields or fixed types that shouldn’t change once the object is created.

public class BankAccount {
    private String accountType = 'Saving';

    public String getAccountType {
        get { return accountType; }
    }
}

Write-only properties

To be fair, you won’t use these every day. But they’re useful for sensitive data. If you have a secret token or a password, you might want to let a user set it, but you definitely don’t want to provide a way for them to read it back out. It’s a niche use case, but it’s a good tool to have in your kit.

The power of custom logic in setters

This is probably the most overlooked feature of Apex properties. You can actually put code inside the set block. This is the perfect place for validation. Instead of checking a value every time you call a method, you can bake the rules right into the property itself.

public class BankAccount {
    private Decimal _balance;

    public Decimal balance {
        get { return _balance; }
        set {
            if (value >= 0) {
                _balance = value;
            } else {
                throw new IllegalArgumentException('Balance cannot be negative.');
            }
        }
    }
}

Pro tip: Use the underscore prefix (like _balance) for your private backing variables. It makes it crystal clear which variable is the “real” data and which one is the property. It’s a small habit that saves a lot of confusion during code reviews.

Static and Automatic properties

Look, sometimes you just need a quick placeholder. Automatic properties are your best friend here. They require zero custom code and are perfect for simple data transfer objects (DTOs). You can still control access by mixing and matching get and set levels.

public integer MinAge { get; private set; }
public double BalanceAmount { get; set; }

Then you have static properties. These live at the class level rather than the instance level. I’ve used these for things like global settings or simple caches within a single transaction. Just remember that they can’t touch instance-level data, which is a common mistake that trips people up.

I’ve often seen this topic pop up in a Salesforce developer interview because it shows you understand encapsulation. It’s not just about making the code work-it’s about making it maintainable for the next person who has to touch it.

Best practices for your projects

• Don’t over-engineer: If you don’t need validation, a simple automatic property is fine. Don’t write a custom getter just because you can.
• Keep getters light: A getter should just return a value. If you start doing heavy SOQL queries or complex math inside a get, your performance is going to tank.
• Validate early: Use the set block to catch bad data before it even hits your database. It’s much easier to debug a thrown exception in a setter than a weird data integrity issue later on.
• Use private setters: If you want a property to be read-only to the outside world but changeable within the class, use { get; private set; }. It’s a great middle ground.

Key Takeaways

• Apex properties combine variables and access methods into one clean package.
• They are essential for encapsulation, which keeps your data safe from accidental changes.
• You can add validation logic directly into setters to keep your business rules in one place.
• Read-only and private-set properties help you control exactly who can change what.
• Static properties are perfect for shared data that doesn’t change between instances.

The bottom line

At the end of the day, using Apex properties is about writing code that doesn’t suck to maintain. It makes your classes shorter, your intent clearer, and your data more secure. Whether you’re building a complex integration or just a simple helper class, take a second to think about how you’re exposing your data. A few well-placed properties can save you a lot of headaches down the road. Give them a try in your next project-you’ll notice the difference in your code quality almost immediately.