Perceive Fields and Properties in Kotlin

How Kotlin implicitly implements subject, getter and setter perform for you if you declare a property?

This text was initially revealed at vtsen.hashnode.dev on Jul 30, 2022.

Properties and fields terminologies in Kotlin typically is a bit complicated as a result of technically, Kotlin would not have Fields. You may’t declare a subject. All the things is Properties!

Nonetheless, to keep away from confusion, I favor to outline Fields and Properties individually primarily based on the next:

• Fields are non-public member variables of a category. Reminiscence is allotted.
• Properties are public or protected getter or setter capabilities which let you entry to the non-public fields.

I wish to outline like this as a result of it helps my understanding and it additionally makes issues lots simpler to elucidate.

Implicit Discipline, Implicit Getter/Setter

Let us take a look at this instance. identify is a property.

class Individual {
    var identify = "Vincent"
}

Whenever you declare a property like this, Kotlin implicitly creates subject, getter and setter capabilities for you.

In Java decompiled code, it seems to be like this:

public ultimate class Individual {
   @NotNull
   non-public String identify = "Vincent";

   @NotNull
   public ultimate String getName() {
      return this.identify;
   }

   public ultimate void setName(@NotNull String var1) {
      Intrinsics.checkNotNullParameter(var1, "<set-?>");
      this.identify = var1;
   }
}

As you’ll be able to see, non-public String identify is the sphere (member variable). getName() and setName() are the property getter and setter capabilities (also referred to as property accessors)

Implicit Discipline, Express Getter/Setter

After all, it’s also possible to explicitly outline the property getter and setter capabilities, which additionally generates a really comparable decompiled Java code.

class Individual {
    var identify: String = "Vincent"
        get() { return subject }
        set(worth) { subject = worth }
}

subject is implicitly created right here, which can be known as Backing Fields. Offering property accessors (i.e. get() and set()) to the property is known as Backing Properties.

Express Discipline, Express Getter/Setter

You may explicitly outline Discipline too. Principally the whole lot is express now.

class Individual {  
    non-public var _name:String = "Vincent"  
    var identify: String  
        get() { return _name }  
        set(worth) { _name = worth }  
}

As a substitute of implicit subject, _name is the specific subject right here.

Non-public Set or Backing Properties?

Now, you need the property identify to be learn solely exterior the category. So you’ll be able to prohibit the property setter utilizing non-public set.

For instance:

class Individual {  
    var identify: String = "Vincent"  
        non-public set  
}

Or it’s also possible to use Backing Properties. Take away the set() and alter the var to val.

class Individual {  
    non-public var _name:String = "Vincent"  
    val identify: String  
        get() { return _name }  
}

Each of the code generate the identical decompile Java code as under. Please word, the setName() perform eliminated.

public ultimate class Individual {  
   @NotNull  
   non-public String identify = "Vincent";  

  @NotNull  
   public ultimate String getName() {  
      return this.identify;  
  }  
}

I personally favor non-public set as a result of it has much less code.

Misuse of personal set

However wait, not so quick. What for those who convert the next backing property

class MainViewModel: ViewModel() {
    non-public val _state: MutableState<Int?> = mutableStateOf(null)
    val state: State<Int?> = _state
    /*...*/
}

to non-public set

class MainViewModel: ViewModel() {
    var state: MutableState<Int?> = mutableStateOf(null)
        non-public set
}

It is a excellent instance of misusing the non-public set. What it actually means is you’ll be able to’t assign a brand new variable to state exterior the MainViewModel class. The state variable itself continues to be mutable (which implies you’ll be able to modify its worth).

The backing property above exposes solely the learn solely State, altering it to non-public set defeats its authentic goal. So, on this situation, you do not use the non-public set. This is applicable to any mutable information.

Conclusion

I believe it is very important perceive the fields and properties ideas right here.

Whenever you declare a property, it would not allocate a brand new reminiscence as a result of it’s merely a getter or setter perform. Nonetheless, if implicit subject implementation is inferred (like code examples above), then sure, it takes up the reminiscence allocation.

Lastly, do not convert each backing property to non-public set. You should not do this, particularly your information is mutable.

See Additionally