Backing Fields

Explanation of backing fields, when they are generated and how to access them inside custom accessors

— — — — — — — — — — — — — — —

THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.

— — — — — — — — — — — — — — —

Tags: #KOTLIN FEATURE

This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.

It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.

This part can appear complicated and a little confusing, but it’s actually not — the compiler takes care of everything behind the scenes, so this part is really just FYI. Basically, this section could be condensed into the sentence “if you need to access the backing field inside an accessor, use field (i.e. field = 3 or field + 5)".

However, I think it’s useful to realize that not all properties require backing fields to be generated — it all depends on the property actually needing to hold a value in memory. The property stringRepresentation in the previous lesson is an example of a property which doesn't need a backing field — it only operates on values of other properties. The Kotlin compiler detects this and doesn't generate a backing field, saving memory.

To refresh your memory, here’s the code we’re talking about:

This would be the equivalent code in Java:

class FullName {
    private String firstName;
    private String lastName;

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(final String newFirstName) {
        firstName = newFirstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(final String newLastName) {
        lastName = newLastName;
    }

    public String getStringRepresentation() {
        return "First name is '" 
            + firstName 
            + "', last name is '" 
            + lastName + "'";
    }

    public void setStringRepresentation(String stringRepresentation) {
        int spaceIdx = stringRepresentation.indexOf(" ");
        if (spaceIdx != -1)
        {
            firstName = stringRepresentation.substring(
                0,
                spaceIdx
            );
            lastName = stringRepresentation.substring(spaceIdx);
        }
        else {
            firstName = " ";
            lastName = stringRepresentation;
        }
    }
}

However, when a property does need a backing field, the compiler figures it out and provides it automatically. This backing field can be referenced in the accessors using the field identifier:

A backing field will be generated for a property if it uses the default implementation of at least one of the accessors, or if a custom accessor references it through the field identifier.

It should be noted that initializers are (naturally) only allowed when there is a backing field. Assigning a value to a property without a backing field results in a compile-time error.

This approach covers the vast majority of cases, but if you want to do something that does not fit into this “implicit backing field” scheme, you can always fall back to having a backing property:

Go back to Accessors, jump to the Table of Contents, or continue to Accessors, continued.