Getter Methods
A getter method in Apex is the public accessor that hands the value of a class member back to whatever code asks for it.
Definition
A getter method in Apex is the public accessor that hands the value of a class member back to whatever code asks for it. The classic shape is a private instance variable holding the data, plus a public method (or property accessor) that returns it without changing anything. Apex supports the Java-style getX() method form and the shorter property form with get and set blocks, and both compile to the same underlying method on the class.
Getters show up most in Visualforce controllers, where a page expression like {!accountName} resolves to a getAccountName() method or an accountName property on the controller. They also appear in Lightning Web Component JavaScript, where a getter computes a value for the template, and behind @AuraEnabled Apex methods that feed data to components. A getter can return a plain field, or it can compute, lazy-load, or cache, which is where most of the design decisions live.
How getters work across Apex and the Salesforce UI layers
Method form versus property form
Apex gives you two ways to write the same accessor. The method form is the Java convention: public String getAccountName() { return acc.Name; }. The property form is shorter: public String accountName { get { return acc.Name; } set; }. Both produce the same public method once compiled, so a caller cannot tell them apart. Property accessors arrived in the Summer 08 release and gave Apex a more compact syntax for field-backed values. The property form reads cleanly when the body is a simple return. The method form earns its extra characters when there is real computation inside, because the verbose signature signals to the next reader that the call does work. Pick one style per class and stay consistent. Mixing getAccountName() with a contactName property in the same file makes the code harder to scan. The key rule is that a property accessor is not magic. It is a method with friendlier syntax, and it obeys the same visibility, return-type, and override rules as any other method you declare.
Automatic properties and access control
Apex lets you omit the body of an accessor and the compiler fills it in. public double MyReadWriteProp { get; set; } creates a hidden backing field with a plain getter and setter. You can drop either side. public Integer MyReadOnlyProp { get; } is read-only, and public String MyWriteOnlyProp { set; } is write-only. Read-only automatic properties are the right shape for a value set once during construction and never changed afterward. You can also put an access modifier on a single accessor. public String accountName { get; private set; } exposes the value to outside callers through the getter but blocks external writes, because the setter is private to the class. This is the standard pattern for derived totals, computed flags, or any field that should stay stable after the object is built. When a property is accessed, either the getter or the setter runs, never both in the same operation. Reading the value always calls get, and assigning to it always calls set.
Visualforce binding to getters
A Visualforce expression such as {!accountName} tells the framework to find a public no-argument getter on the page controller or any attached extension. It looks for a method named getAccountName or a property named accountName, and it calls that accessor to fill the merge field. The catch is how often this happens. Visualforce evaluates the expression on the first render and again on every rerender triggered by an action or a rerender attribute. If the getter runs a SOQL query, that query fires every single time the page paints. A getter referenced from several spots on one page can run its query several times in a single request. The fix is a private backing field. The first call queries and stores the result, and later calls return the stored value. Uncached SOQL inside a getter is the most common performance trap in custom controllers, and it often hides because the code looks like a harmless property read. Treat any getter that touches the database as something to cache.
Getters in Lightning Web Components
Lightning Web Components use JavaScript getters to compute values for the template instead of putting logic in the markup. A getter named uppercaseName can return this.name.toUpperCase(), and the template binds to it as {uppercaseName}. The component re-evaluates the getter whenever a reactive field it reads changes, so the displayed value stays current. There is a specific rule for public properties. If you write a setter for an @api property, you must also write a getter, and you annotate only one of the two with @api, not both. The convention is to store the value in a private field named with a leading underscore, then expose it through the accessor pair. This pattern lets you run logic each time the public property is assigned, such as transforming or validating the incoming value. The getter form keeps the template declarative and pushes the computation into the class where it can be tested. Keep these getters cheap, because the framework may call them often during reactive updates.
@AuraEnabled methods as data getters
When a Lightning Web Component or Aura component needs server data, it calls an Apex method marked @AuraEnabled. These methods act as getters across the network boundary. A method marked @AuraEnabled(cacheable=true) has its result stored in the Lightning client-side cache, so repeat calls with the same arguments come back from cache rather than running Apex again. That removes the call from the server transaction entirely until the cache is invalidated. The rule is that a cacheable method must not change data. It cannot run DML, and it should read only. Methods that mutate state are called imperatively and never marked cacheable. So the discipline matches the getter mindset on the client side: read-only methods that return a value are the ones you mark cacheable, and anything that writes stays a separate imperative call. Marking a read-only method cacheable is one of the simplest ways to cut redundant server round-trips in a component, and forgetting to do it leaves easy performance on the table.
Keeping getters side-effect free
Every consumer of a getter expects it to return a value and leave the world unchanged. Visualforce, Lightning, and managed-package callers all assume a read does not perform DML, fire a callout, or flip internal flags. Break that assumption and strange bugs follow. A getter that issues a query inflates the SOQL count during page render in a way that looks impossible to trace, because the query is hidden behind what reads like a simple field access. A getter that does DML can fail mid-render or push a transaction into a governor limit. The lazy-load pattern is the one acceptable form of internal state. The first call queries and caches into a private field, and later calls return the cached value, which saves work without surprising the caller. When you genuinely need to change state, do not bury it in a getter. Write a method with a clear action verb such as refresh, load, save, or fetch, so the name announces that calling it does something. Reserve get for pure reads.
Getters and test coverage
Apex requires 75 percent code coverage before you can deploy to production, and getters count toward that number. A trivial property that just returns a field is usually covered for free once any test touches the object. Computational and lazy-load getters are different. They contain branches, so they need a test that instantiates the class, calls the getter, and asserts the returned value. A lazy-load getter often needs two calls in the test, one to populate the cache and one to confirm the cached path returns the same result. Skip these tests and the gap does not show up until deployment, when the org reports a coverage failure on a class you thought was finished. Writing the getter test alongside the getter keeps coverage honest and documents the expected output. If a getter contains hidden DML or a callout, the test will usually expose it as an unexpected failure or a limit exception, which is a good reason to never weaken the assertion to make a test pass. Fix the getter instead.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Getter Methods.
Hands-on resources to go deeper on Getter Methods.
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 is the role of a Getter Method inside a Visualforce Apex controller?
Q2. Why should Apex getter methods be kept side-effect free in practice?
Q3. Given that Lightning Web Components are the modern path, how do getter methods fit new development?
Discussion
Loading discussion…