A practical guide to Apex properties: what they are, types (read-only, write-only, read-write), automatic and static properties, and best practices with code examples to make your Apex classes cleaner and safer.
What are Apex properties?
In Apex, properties provide a concise syntax that combines getter and setter logic for class fields. They act as intermediaries between private fields and external code, enabling encapsulation, validation, and clearer APIs for your classes.
Basic property example
Use properties to expose values without writing separate getter/setter methods:
public class ContactDetail {
public String contactName { get; set; }
}
Types of Apex properties
1. Read-only properties
Read-only properties allow external code to retrieve values but not modify them. Useful for values that should remain constant or controlled by the class.
public class BankAccount {
private String accountType = 'Saving'; // Private field
// Read-only property
public String getAccountType {
get { return accountType; }
}
}
2. Write-only properties
Write-only properties accept values from external code but prevent reading. These are less common but can be useful for sensitive data.
public class AccountDataHandler {
private String secretCode;
// Write-only property
public String secretCodeProperty { set { secretCode = value; } }
}
3. Read-write properties
Read-write properties are the most common. You can embed validation and business logic in the setter to enforce rules when values change.
public class BankAccount{
private Decimal _balance;
public Decimal balance {
get { return _balance; }
set {
if (value >= 0) { // Ensuring balance is non-negative
_balance= value;
} else {
throw new IllegalArgumentException('Balance cannot be negative.');
}
}
}
}
Automatic properties
Automatic properties use empty get/set accessors for concise code. They can be read-only, write-only, or read-write.
public integer MinAge{ get; }
public double BalanceAmount{ get; set; }
public string BranchName{ set; }
Static properties
Static properties run in a static context and cannot access instance member variables. They’re helpful for values 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 and control access to fields.
- Simplified syntax: reduces boilerplate compared to explicit getter/setter methods.
- Custom logic: add validation and business rules inside setters/getters.
- Maintainability: properties make code easier to read and maintain.
When to use properties
Use properties when you need controlled access to class data, want to embed validation, or keep your API concise for other developers and integrations. Prefer read-only properties for derived or constant data, write-only for sensitive ingestion-only values, and read-write when you need validation on set.
Conclusion: Why this matters for Salesforce teams
Understanding and using Apex properties improves code quality, enforces business rules at the class boundary, and reduces bugs introduced by uncontrolled field access. For Salesforce admins, developers, and business users, properties mean safer data handling, clearer APIs for integrations, and cleaner, more maintainable Apex code.