Getter Methods
Getter Methods in Apex are the public accessors that expose the value of a class property to outside callers.
Definition
Getter Methods in Apex are the public accessors that expose the value of a class property to outside callers. The pattern follows standard object-oriented practice: a private instance variable holds the data, and a public method (or property accessor) returns it. Apex supports the explicit Java-style getX() naming convention and the more concise C#-style property syntax with implicit get and set blocks, both compiling to the same underlying method.
Getter methods appear most often in Visualforce controllers, where every public property on the controller class is exposed to the page via {!propertyName}, and in Lightning Web Component @AuraEnabled methods, where they let JavaScript read computed values from Apex. Getters can hold computation, lazy loading, caching, or pure field returns. The trade-off is the same as in any platform: pure getters are predictable; computational getters can be slow when called inside loops or rendered many times per page request.
How getters power Visualforce, Aura, and LWC controllers
Java-style getX() versus property syntax
Apex supports two ways to write a getter. Old-style: public String getAccountName() { return acc.Name; }. Property style: public String accountName { get { return acc.Name; } set; }. Both compile to the same underlying public method on the class, and Visualforce can call either with {!accountName}. The property syntax is cleaner for simple field-backed accessors; the method syntax is clearer when there is meaningful computation inside.
Visualforce binding to getters
Visualforce expressions like {!accountName} look up a getter on the page controller (or any controller extension). The framework looks for a public no-argument method named getAccountName or a public property named accountName. Calling the expression evaluates the getter on every render or rerender; long-running computation inside a getter slows the entire page. Cache the result in a private field when the getter is called more than once per page lifecycle.
@AuraEnabled getters for Lightning
Lightning Web Components and Aura Components call Apex via @AuraEnabled methods. Methods marked cacheable=true behave like getters on the network: the platform caches the response in the Lightning Data Service cache and serves subsequent calls from cache until invalidated. Non-cacheable @AuraEnabled methods always hit Apex. Mark read-only Apex methods cacheable; mutating methods cannot be marked cacheable and must be called imperatively.
Side-effect-free getters
Apex getters should be side-effect free. Visualforce, Lightning, and managed-package consumers expect a getter to return the value without changing state, performing DML, or making callouts. Side-effects inside a getter break test predictability, cause unexpected SOQL counts during page render, and trip the standard governor limits in ways that look impossible to debug. Use a method with a clear verb name (refresh, load, fetch) when state change is required.
Lazy-loading getters
The most common useful pattern beyond pure field returns is the lazy-load getter: the first call queries the data and caches the result in a private field; subsequent calls return the cached value. The pattern saves SOQL when the page renders many times or when the value is referenced from multiple expressions on the same page. The cost is mutable internal state, which complicates testing.
Getter-only properties
Apex supports get-only properties: public String accountName { get; private set; }. The property exposes the value to outside callers (via the getter) but blocks external writes (the setter is private). This is the right shape for derived values, computed totals, or any field that should not be modified after construction. Pair with a constructor that sets the value during instantiation.
Getters and test coverage
Apex tests must achieve 75 percent coverage to deploy. Trivial property getters count toward coverage, but lazy-load or computational getters need explicit test paths. Write a test method that instantiates the controller, calls the getter, and asserts the returned value. Skipping these tests leaves blind spots that show up at deployment time as coverage failures on the production org.
Write a clean getter on a Visualforce controller
The shortest path is the property syntax with a private backing field and an explicit lazy-load check. The pattern handles 90 percent of controller getter needs.
- Declare the backing field as private
private Account cachedAccount; The field holds the loaded value across multiple getter calls inside the same controller instance.
- Add the property with a custom get block
public Account currentAccount { get { if (cachedAccount == null) cachedAccount = [SELECT Id, Name FROM Account WHERE Id = :recordId LIMIT 1]; return cachedAccount; } private set; }
- Reference the property from Visualforce
{!currentAccount.Name} on the page now reads through the property; the SOQL runs once even if the expression appears five times.
- Invalidate when state changes
When the controller takes an action that changes the underlying record, set cachedAccount = null inside the action method so the next getter call refreshes the data.
- Write the unit test
Create an Account in the test, instantiate the controller with the record ID, call currentAccount, and System.assertEquals on the returned name.
Must be public to be reachable from Visualforce or Lightning bindings.
Any Apex type; primitive, sObject, or custom class.
Java-style getX or C#-style property name. Visualforce maps both to the same expression syntax.
Required to call the getter from JavaScript; add cacheable=true for read-only methods.
- Getters with SOQL run on every Visualforce rerender. A page with five expressions referencing five different SOQL-heavy getters can fire 25 queries per render without caching.
- Side effects inside getters are an anti-pattern. Modifying state, performing DML, or making callouts from a getter breaks the implicit contract that getters are read-only.
- Lazy-load caching survives only inside the controller instance. Visualforce controllers are recreated on each request; the cache does not persist across requests unless persisted to ViewState.
- @AuraEnabled cacheable=true methods cannot perform DML. Mark a method cacheable only when it is genuinely read-only.
Trust & references
Cross-checked against the following references.
- Apex PropertiesSalesforce Developers
- Visualforce ControllersSalesforce Developers
Straight from the source - Salesforce's reference material on Getter Methods.
- Apex MethodsSalesforce Developers
- AuraEnabled AnnotationSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does a Getter Method do?
Q2. Where are getter methods most commonly used?
Q3. Should you use getter methods in new development?
Discussion
Loading discussion…