[SalesForce] Overriding Getters and Setters from Base Class

I'm trying to convert an old global class to be a virtual class so I can have some variations on its implementation. There is some existing behavior on the property Getters that I'd like to preserve in one of my new concrete subclasses.

The parent looks something like this:

global virtual class TestParent {
    global String myName {get;set;}
    global virtual void sayHi() { }
}

And the subclass looks like this.

global class TestChild extends TestParent {
    global String getMyName() {
       return myName + ' Smith';
    }
    global override void sayHi() {
        System.debug('Hello, ' + myName );
    }    
}

What I'd like to do is be able to override the {get;} defined on my parent class in the subclass to perform some logic against the accessed attribute.

My thinking above was that global String myName {get;set;} would translate to a getMyName() method, but the property can't override it that way. Because the parent call is released as global, I need to continue being able to access the Child class the same way I used to access the Parent class, so I can't change it's implementation unless it continues exposing the same outward API.

Any help appreciated.

Best Answer

You can do this, but it's not straight-forward. You need to set up the parent and child as follows:

global virtual class TestParent {
    protected virtual String getName() {
        return protectedName;
    }
    protected String protectedName;
    public String myName { get { return getName(); } set { protectedName = value; } }
}
global class TestChild extends TestParent {
    protected override String getName() {
        return 'Hello there.';
    }
}

Related Solutions

[SalesForce] When and how getters and setters are called

Visualforce performs some coercion on values retrieved from getters to avoid certain error conditions. For example, consider this expression:

<apex:outputText value="Hello World" rendered="{!boo}" />

If boo (as above), were allowed to return null, an error would happen. Try rendering this in Apex Code to see what happens:

// Page constructor in Apex Code
public GetterSetterCon() {
    if(boo) {
        ApexPages.addMessage(new ApexPages.Message(ApexPages.Severity.INFO, 'Hello World'));
    }
}

Note that this code crashes on page load with a null pointer exception, even though boo returns false in your example.

Visualforce is generally a bit more type-safe than Apex Code is, although you should still be aware of trying to render non-existent map keys.

You won't see this in the debug logs, because it doesn't occur in a way that's visible to the developers. Null renders as "nothing" in most cases, but renders as false in the case of boolean.

Running iterators, like apex:repeat, across a null list won't crash the page either; it treats it as if it were a simple empty list.

Perhaps the most important piece of advice I can give to a new developer is to never leave variables uninitialized. Other languages tend to either provide default values for uninitialized values, or provide compile-time errors. Apex Code and Visualforce do neither (generally, but there are exceptions), so you should always make sure you've initialized your variables. Special exceptions to default initialization are noted in the documentation.

[SalesForce] Apex Properties vs. normal setters and getters

The Apex Properties method is typically used as part of a Visualforce controller when you have an action method that calls a method within a controller where you also expect to return or "set" a value. Below is a "lazy" load example where rather than explicitly setting the value, it returns it when called and only when the existing value is null.

public Account getMyAccount() {
   if (MyAccount == null) {
      MyAccount = [SELECT name, annualRevenue FROM Account
      WHERE
      id = :ApexPages.currentPage().getParameters().
      get(‘id’)];
   }
   return MyAccount;
}

Note that this type of code is used to implicitly set all of the field values related to the Account that are returned in the query. It could have been coded to specifically set each field as well. The above is more efficient, allowing the page to use what it needs.

Edit:

Lazy loading is described in the pdf Visualforce in Practice. How a page loads and the order in which things are evaluated can be rather complex in a Visualforce page depending on the custom controller, the page's design and any user actions taken. This is discussed in the Visualforce Developer’s Guide in the section titled Order of Execution in a Visualforce Page where you'll find examples that illustrate the concepts involved.

Related Topic

[SalesForce] LWC best practices: Getters for derived values vs. setters for controlling values