In this section, we're going to discuss properties in Kotlin. You might already know the concept of Java being property. Unlike Java where a property is not a language construct. Kotlin supports it as a separate language feature. In a most common scenario for a trivial case, property syntaxes are really concise. But you can customize it if needed. Java classes contains fields and methods inside. They don't have the direct feature of property. However, if you define a field with the corresponding getter and setter in Java, that concept will be considered a property. For instance, a filed foo together with getFoo and setFoo methods is called the foo property. In Kotlin, a property is absolutely the same idea, the same concept. The syntax is different. You define the property itself rather than separately fields and accessors. But under the hood, the implementation doesn't change. It's the same field and accessors as in Java. When you use a property in Kotlin, you don't call getters or setters. You use properties directly and access it like a variable. When you access the property by its name, the getter is called under the hood. If you want to change its value to call a setter, you do it like it was a variable. Under the hood, the setter is called. If you use the Kotlin properties from Java, you will need to call getters and setters explicitly like in Java. And Java code looks like Java. Interestingly, there is no difference whether this contact class is defined in Kotlin or in Java. If you define a Java class with a field getter and its probably setter following the convention, then in the Kotlin you can use it as a regular Kotlin property. You access Java properties from Kotlin by their names not via getters and setters. They usage of properties now looks much nicer. The question for you. How many methods does the class Person have under the hood? Note that we don't count the constructors here. We have one on the property name, which has the corresponding getter under the hood and a mutable property age, which has a getter and setter, getAge and setAge, that makes it 3 as a result. This is the Person class written in Java and at the same time, that's what's going on under the hood. At the bytecode level, we have the same implementation as in Java, two fields, constructor, two getters and a setter. The Kotlin syntax looks nice, straightforward and concise, while the bytecode stays the same. You can define properties without fields. Like in Java, when you can only define getFoo method that returns a value. If you don't need a field, you omit it. You can do define the accessors behavior without the necessity to store a value in a field. Here, we define a custom getter for the isSquare property, which is calculated on each access. From Kotlin, you use the isSquare property as a regular property, there is no difference. The question for is, how many times the phrase, calculating the answer, will be printed in this example? We use the run function that we've discussed in the previous module. It runs the lambda and returns it's result, the last expression. We assign 42 to a variable foo1 and print calculating the answer on the way. The lambda result is calculated only once when we assign it, then the property value is used. Therefore, the phrase calculating the answer is printed only once here. In the second example, the foo2 property has a custom getter which is called on each access. Every time we call the property, the getter is called and the calculating the answer phrase is printed. That gives us 3 as the number of times the phrase will the printed. Let's now talk about fields. In Kotlin, you don't work with fields directly, you work with properties. However, if you need, you can access a field inside its property accessors. It's not visible for other methods of the class. You access a field inside its getter or setter by using the field keyboard. Here, we have access a field inside a custom setter. We had log in to mark the situation when the property value was changed. Note that no backing field is generated by the compiler if you define acessors and don't use field keyword there. Here, state mutable property uses another private property boolState to store the data. State only delegates to it. Because state doesn't use field keyword inside its getter and setter, no baking field is generated for it. If you don't define accesors for a property, the compiler generates a trivial getter that returns the field value, and a trivial setter updating the value, if the property is mutable. You don't access field's getters or setters directly, you only use properties both inside and outside of the class. I want to highlight here that under the hood the gutters and setters are called. When you access counter here, then as the bytecode, getCounter is called instead. However, inside of the class, the optimization takes place. If the property accessors are trivial, their default ones, which return you the value or assign it, then the call is optimized by the compiler, and replaced with accessing the field directly. It's not safe to perform this optimization for code outside of the class. You might want to change the implementation of the getter, making it non trivial. Then you will need to recompile the depending code so that it use the getter instead of the field. However, in general case, you can use different versions of the class and the depending code so such property change won't be safe. The older depending code will continue to use the old trivial property implementation. To prevent such problems, outside of the class getters and setters are always called in the generated bytecode. But inside the class, optimization performed by the compiler are possible, but only for the trivial properties. Sometimes you want a var mutable property to be accessible only as a read-only property outside of the class. For that, you can make a setter private. Then the getter is accessible everywhere. And therefore the property is accessible everywhere. But it's allowed to modify it only inside the same class. Note that we change only the visibility of the setter, but use the default implementation. We've discussed redundant mutable properties, how to define custom getters and setters, and how to mix Kotlin properties and Java. Next, we are going to talk about defining properties in interfaces and making them extensions.
