Apex properties provide a concise way to encapsulate fields with getter and setter accessors, enabling validation, encapsulation, and cleaner code. This post explains types, examples, and best practices for using Apex properties in Salesforce development.
What are Apex properties?
Apex properties are a shorthand syntax that combine getter and setter methods in an Apex class. They act as intermediaries between a class’s private fields and external code, offering a clear and controlled way to retrieve and modify values while keeping implementation details hidden.
Basic example
Here’s a simple example showing a public property that exposes a private field:
public class ContactDetail {
public String contactName { get; set; }
}
Types of Apex properties
Read-only properties
Read-only properties allow external code to read a value but not modify it. These properties implement only a getter and are useful when you need controlled, immutable exposure of data.
public class BankAccount {
private String accountType = 'Saving';
// Read-only property
public String getAccountType {
get { return accountType; }
}
}
Write-only properties
Write-only properties allow values to be set externally but not read. They are less common but useful for accepting sensitive data (e.g., secret tokens) without exposing them.
public class AccountDataHandler {
private String secretCode;
// Write-only property
public String secretCodeProperty { set { secretCode = value; } }
}
Read-write properties
Read-write properties are the most common and allow both getting and setting a value. Setters are the ideal place to implement validation, transformation, or business logic.
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
Automatic properties require no custom code in the accessors and are useful for concise, boilerplate-free data exposure. They still support read-only, read-write, or write-only behavior.
public integer MinAge { get; }
public double BalanceAmount { get; set; }
public string BranchName { set; }
Static properties
Static properties run in the static context and cannot access instance-level members. They are appropriate for values or calculations shared across the class.
public class CustomerDiscount {
private static Decimal purchaseTotal = 5000;
public static Decimal discount {
get { return purchaseTotal > 1000 ? 0.1 * purchaseTotal : 0; }
}
}
Benefits and best practices
- Encapsulation: Hide implementation details behind accessors to protect data integrity.
- Simpler syntax: Use properties rather than separate get/set methods to reduce boilerplate.
- Validation in setters: Centralize input validation and transformation in one place.
- Prefer immutability where possible: Use read-only properties for values that shouldn’t change after construction.
- Avoid heavy logic in getters: Keep getters lightweight to prevent side effects and performance issues.
Use cases
- Data validation — ensure values meet business rules before being saved.
- Computed values — expose derived data via read-only properties.
- Controlled visibility — hide sensitive fields while allowing controlled updates.
Conclusion – Why this matters
Using Apex properties leads to cleaner, more maintainable code and helps enforce business rules consistently. For Salesforce admins and developers, properties reduce bugs, centralize validation, and improve collaboration between declarative and programmatic layers. Business users benefit from more predictable behavior and data integrity.
References