A concise guide to Apex properties: what they are, the types (read-only, write-only, read-write), automatic and static properties, and how they improve encapsulation and code quality in Salesforce Apex.
What are Apex Properties?
In Apex, properties provide a shorthand way to expose class data via combined get and set accessors. They act as intermediaries between private fields and external code, allowing controlled access to values while keeping implementation details encapsulated. Properties are useful for adding validation, business logic, or computed values without bloating the API of your class.
Types of Apex Properties
Apex supports several property patterns — each serves a purpose depending on access needs:
- Read-only: Exposes a value externally but prevents modification. Useful for derived values or constants.
- Write-only: Allows data to be set but not read externally. Rare, but handy for secrets or single-direction updates.
- Read-write: The common pattern that enables validation or transformation in the setter.
Examples
Read-write property with validation:
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.');
}
}
}
}
Automatic properties (concise syntax):
public integer MinAge{ get; }
public double BalanceAmount{ get; set; }
public string BranchName{ set; }
Static property example (accessors run in static context):
public class CustomerDiscount {
private static Decimal purchaseTotal = 5000;
public static Decimal discount {
get { return purchaseTotal > 1000 ? 0.1 * purchaseTotal : 0; }
}
}
Why use Apex Properties?
- Encapsulation: Hide implementation and control how data is accessed or modified.
- Clearer code: Properties reduce boilerplate getter/setter methods and improve readability.
- Built-in validation: Add checks and business logic right where values are assigned or retrieved.
- Maintainability: Easier to change internal behavior without changing the external API.
Best Practices
- Prefer read-only properties for derived or computed values.
- Use validation in setters to enforce invariants and avoid corrupt state.
- Limit use of write-only properties — document intent clearly if used.
- Remember static accessors cannot reference instance members.
Use Cases
Apex properties are ideal when you need: data validation on assignment, computed fields that depend on other members, hiding sensitive internals, or simplifying public APIs for utility classes and domain objects.
For Salesforce admins and developers, using properties consistently will lead to cleaner triggers, services, and controllers — and fewer bugs caused by uncontrolled field updates.
References