Writing effective setter methods in Apex

Writing effective setter methods in Apex is mostly about deciding when to use the automatic property syntax versus an explicit setter with custom logic. The four-step routine covers: pick the right syntax for the property, add validation and normalization logic where appropriate, document dependencies between setters, and test the setters explicitly in unit tests. Each step is a small decision; the cumulative effect on code quality is large. Mature Apex codebases keep setter logic short and predictable; long setters with side effects become maintenance debt quickly.

1. 1
   Pick the right syntax for the property

   For simple properties that just hold a value with no logic, use the automatic property syntax: public String myProperty with get and set blocks. The compiler generates the getter and setter. For properties that need validation, normalization, or side effects, write the explicit setter: public void setMyProperty(String value) with custom logic then assign this.myProperty equals value. The decision is per-property; some properties in the same class use automatic syntax while others use explicit setters. Document the rationale in a comment when explicit setters are used for non-obvious reasons; future maintainers may wonder why the property does not use the automatic syntax.

2. 2
   Add validation and normalization logic where appropriate

   For properties that need validation (the value must be in a specific range, the email must be properly formatted, the picklist value must match the allowed list), add explicit setter logic that checks the value and either throws an exception or rejects the assignment. For properties that need normalization (trim whitespace, lowercase, format as a phone number), add the normalization in the setter so every entry path through the property produces consistent data. Keep the validation and normalization logic short; long setter logic slows down every form submission and complicates testing.

3. 3
   Document setter dependencies

   When Setter B depends on the value Setter A assigned (a calculation, a related field update), the order in which the platform calls the setters matters. The platform calls setters in the order the corresponding fields appear in the Visualforce markup, so the dependency works as long as A field appears before B field on the page. Document this dependency in a comment on both setters so future maintainers do not move the fields around and break the calculation. For complex dependency chains, consider moving the dependent logic to the action method instead, where the order is explicit.

4. 4
   Test setters explicitly in unit tests

   Write Apex test methods that exercise the setters directly: create the controller instance, call the setter with sample values (valid, invalid, edge cases), and assert the resulting controller state. For setters with side effects on related records, also assert the side effects in the test. Mock external dependencies (HTTP callouts, custom settings) with the standard test mocking patterns. Aim for high test coverage on setter logic; setters are where most input-validation bugs hide, and good coverage catches them before they reach production. Add the setter tests to your CI pipeline so changes to setter logic get validated automatically.