public enum class Word : Printable { HELLO {
override fun print() { println("Word is HELLO") }
}, BYE {
override fun print() { println("Word is BYE") }
} }
val w= Word.HELLO w.print()
Static methods and companion objects
Unlike Java, Kotlin doesn't support static methods for a class. Most readers will know that static methods do not belong to the object instance but rather to the type itself. In Kotlin, it is advisable to define methods at the package level to achieve the functionality of static methods. Let's define a new Kotlin file and name it Static. Within this file, we will place the code for a function that will return the first character of the input string (if the input is empty, an exception will be raised), which is as follows:
fun showFirstCharacter(input:String):Char{
if(input.isEmpty()) throw IllegalArgumentException() return input.first()
}
Then, in your code, you can simply call showFirstCharacter("Kotlin is cool!").
The compiler is here to do some of the work for you. Using javap, we can take a look at the byte code generated. Just run javap -c StaticKt.class to get the code produced by the compiler:
Compiled from "Static.kt"
public final class com.programming.kotlin.chapter03.StaticKt { public static final char showFirstCharacter(java.lang.String);
Code:
As you can see from the printout, the compiler has actually generated a class for us and has marked it as final; it can't be inherited, as you already know. Within this class, the compiler has added the function we defined. Let’s call this method from the program entry point and again using the utility javap we can look at what the bytecode looks like:
fun main(args: Array<String>) {
println("First lettter:" + showFirstCharacter("Kotlin is cool")) }
Compiled from "Program.kt"
public final class com.programming.kotlin.chapter03.ProgramKt { public static final void main(java.lang.String[]);
Code:
Most of the bytecode has been left out for the sake of simplicity, but at line 20 you can see there is a call to our method; in particular, the call is made via the invokestatic routine.
We can't talk about static methods and not bring singletons into the discussion. A singleton is a design pattern that limits the instantiation of a given class to one instance. Once created, it will live throughout the span of your program. Kotlin borrows the approach found in Scala. Here is how you can define a singleton in Kotlin:
object Singleton{
From any function, you can now call Singleton.doSomething, and each time, you will see the counter increasing. If you were to look at the bytecode produced, you will find out the compiler is doing some of the work for us once again:
public final class com.programming.kotlin.chapter03.Singleton {
public static final com.programming.kotlin.chapter03.Singleton INSTANCE;
public final void doSomething();
Code:
I have left out the code produced for our doSomething method since it is not the focus of this topic. The compiler once again has created a class and marked it final. Furthermore, it has introduced a member called INSTANCE and has marked it static. The interesting part is at the end of the listing where you see the static{}; entry. This is the class initializer, and it is called only once, JVM will make sure this happens, before:
An instance of the class is created A static method of the class is invoked A static field of the class is assigned A non-constant static field is used
An assert statement lexically nested within the class is executed for a top-level class
In this case, the code is called before the first call to doSomething because we access the static member INSTANCE (see the following getstatic bytecode routine). If we were to call this method twice, we would get the following bytecode:
public static final void main(java.lang.String[]);
You can see that in both occasions doSomething is called as a virtual method. The reason is you can create a singleton that inherits from a given class, as in the example here:
open class SingletonParent(var x:Int){
fun something():Unit{
println("X=$x") }
}
object SingletonDerive:SingletonParent(10){}
There is a way to call a static method as you would do in Java. To achieve this, you will have to place your object within a class and mark it as a companion object. This concept of a companion object will be familiar to someone with at least entry-level knowledge of Scala.
The following example uses the factory design pattern to construct an instance of Student:
interface StudentFactory {
fun create(name: String): Student }
class Student private constructor(val name: String) { companion object : StudentFactory {
override fun create(name: String): Student { return Student(name)
} }
}
As you can see, the constructor for the Student type has been marked private. Thus, it can't be invoked from anywhere apart from inside the Student class or the companion object. The companion class has full visibility for all the methods and members of Student.
From the code, you will need to call Student.create("Jack Wallace") to create a new instance of Student. If you look in the build output, you will notice there are two classes generated for Student: one is Student.class and the other is
Student$Companion.class. Let's see how the call to Student.create gets translated into bytecode:
public final class com.programming.kotlin.chapter03.ProgramKt { public static final void main(java.lang.String[]);
Code:
At line 6, you will notice there is a call for a static member getstatic. As you can probably imagine, there is a static field added to the Student class of the type Student.Companion:
public final class com.programming.kotlin.chapter03.Student {
public static final com.programming.kotlin.chapter03.Student$Companion Companion;
public final java.lang.String getName();
static {};
com/programming/kotlin/chapter03/Student$Companion."<init>":(Lkotl in/jvm/internal/DefaultConstructorMarker;)V
8: putstatic #44 //Field
Companion:Lcom/programming/kotlin/chapter03/Student$Companion;
11: return public
com.programming.kotlin.chapter03.Student(java.lang.String,kotlin.jvm.intern al.DefaultConstructorMarker);
Code:
0: aload_0 1: aload_1
2: invokespecial #24 //Method "<init>":(Ljava/lang/String;)V 5: return
This code snippet proves the assumption is correct. You can see the Companion member being added to our class. And yet again, the class gets class initializer code generated to create an instance of our companion class. Student.create is shorthand for writing code such as Student.Companion.create(). If you were trying to create an instance of Student.Companion (that is, val c = Sudent.Companion), you would get a compilation error. A companion object follows all the inheritance rules.
Interfaces
An interface is nothing more than a contract; it contains definitions for a set of related functionalities. The implementer of the interface has to adhere to the interface the contract and implement the required methods. Just like Java 8, a Kotlin interface contains the declarations of abstract methods as well as method implementations. Unlike abstract classes, an interface cannot contain state; however, it can contain properties. For the Scala developer reading this book, you will find this similar to the Scala traits:
interface Document { val version: Long val size: Long val name: String get() = "NoName"
fun save(input: InputStream) fun load(stream: OutputStream) fun getDescription(): String {
return "Document $name has $size byte(-s)"}
}
This interface defines three properties and three methods; the name property and the getDescription methods provide the default implementation. How would you use the interface from a Java class? Let's see by implementing this interface:
public class MyDocument implements Document { public long getVersion() {
return 0;
}
public long getSize() { return 0;
}
public void save(@NotNull InputStream input) { }
public void load(@NotNull OutputStream stream) { }
public String getName() { return null;
}
public String getDescription() { return null;
} }
You can see the properties have been translated into getters. Despite providing default implementations for getDescription along with the name, you still have to implement them. This is not the case when implementing the interface in a Kotlin class:
class DocumentImpl : Document { override val size: Long get() = 0
override fun load(stream: OutputStream) { }
override fun save(input: InputStream) { }
override val version: Long get() = 0
}
Let's delve into the generated code and see what actually happens behind the scenes with the code for those two methods implemented at the interface level:
$ javap -c
1: invokespecial #32 //Method java/lang/Object."<init>":()V 4: return
com/programming/kotlin/chapter03/Document$DefaultImpls.getDescription :(Lcom/programming/kotlin/chapter03/Document;)Ljava/lang/String;
4: areturn }
You may have already spotted the calls to the DefaultImpls class in the code of getDescription and getName. If you look into the classes produced by the compiler (build/main/com/ programming/kotlin/chapter03), you will notice a file
named Document$DocumentImpls.class. What is this class all about, I hear you ask? You haven't written such a class. We can find out what it contains by again turning to javap:
public final class com.programming.kotlin.chapter03.Document$DefaultImpls { public static java.lang.String
getName(com.programming.kotlin.chapter03.Document);
Code:
0: ldc #9 //String NoName 2: areturn
public static java.lang.String
getDescription(com.programming.kotlin.chapter03.Document);
Code:
0: new #14 //class java/lang/StringBuilder 3: dup
4: invokespecial #18 //Method java/lang/StringBuilder."<init>":()V
7: ldc #20 //String Document 9: invokevirtual #24 //Method
java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder
;
12: aload_0
13: invokeinterface #29, 1 //InterfaceMethod
com/programming/kotlin/chapter03/Document.getName:()Ljava/lang/String ; 40: invokevirtual #43 //Method
java/lang/StringBuilder.toString:()Ljava/lang/String;
43: areturn }
From the preceding code snippet (I left out some of the code for simplicity), you can clearly see the compiler has created a class for us containing two static methods that match the ones we have implemented in the interface.
While the code for getName is very simple, after all, we just return a string value, the one for getDescription is a bit more complex. The code makes use of StringBuilder to create the string for description purposes. The interesting part is how it goes back to getSize and getName. If you look at line 12, aload_0 pushes the Document parameter (the method getDescription takes one parameter) to the stack. The next line makes the call by using invokeinterface to call a method defined by a Java interface. Discussing the details of the Java bytecode goes beyond the scope of this book. You can find quite a few details, if you are interested to know more, with a quick search on the Web.
Inheritance
Inheritance is fundamental to object-oriented programming. It allows us to create new classes that reuse, extend, and/or modify the behavior of the preexisting ones. The
preexisting class is called the super (or base or parent) class, and the brand new class we are creating is called the derived class. There is a restriction on how many super classes we can inherit from; on a JVM, you can only have one base class. But you can inherit from multiple interfaces. Inheritance is transitive. If class C is derived from class B and that class B is derived from a given class A, then class C is a derived class of A.
A derived class will implicitly get all the parent classes (and the parent's parent class, if that is the case) fields, properties, and methods. The importance of inheritance lies in the ability to reuse code that has already been written and therefore avoid the scenario where we would have to reimplement the behavior exposed by the parent class. A derived class can add fields, properties, or new methods, thus extending the functionality available through the parent. We would say that class B, the derived one, specializes class A, the parent. A simpler example is to think of the animal kingdom chart. At the top, we have animal, followed by vertebrates and invertebrates; the former is further split into fish, reptile, mammals, and so on. If we take the yellow-fin tuna species, we can look at it as a specialized type of fish.
The next illustration shows a simple class hierarchy. Let's say you write a system to deal with payments. You will have a class called Payment that holds an amount and a CardPayment class to take such payments:
Simple inheritance
You must have noticed the presence of another entity called Any in the preceding screenshot. Every time you construct an entity that doesn't take any parent, it will
automatically get this class as its parent. You will probably think Any is the Object class, the super/parent class of any class defined in Java. However, this is not the case. If you pay attention to the methods defined by the class Any you will notice it is a subset of those found for on the Java Object class. So how does Kotlin deal with Java object references?
When the compiler sees such an object, it will translate it into Any and then it will make use of the extension methods to complete the method set.
Let's implement the preceding code and see how we actually define in Kotlin inheritance:
enum class CardType { VISA, MASTERCARD, AMEX }
open class Payment(val amount: BigDecimal)
class CardPayment(amount: BigDecimal, val number: String, val expiryDate: DateTime, val type: CardType) : Payment(amount)
We have created our classes based on the spec we just saw. CardType is an enumeration type, as hinted in the definition. The definition of Payment has introduced a new keyword, called open. Through this keyword, you are basically saying the class can be inherited from.
The designers of Kotlin have decided the default behavior is to have the classes sealed for inheritance. If you have programmed in Java, you will have come across the final keyword, which does exactly the opposite of open. In Java, any class which hasn't been marked as final can be derived from. The definition of CardPayment marks the
inheritance via a semicolon. The : Payment translates into: “CardPayment which extends from Payment“. This is different to Java where you would use the extends keyword. Any
In the preceding code, our CardPayment class has a primary constructor. Therefore, the parent one has to be called on the spot, hence Payment(amount). But what if our new class doesn't define a primary constructor? Let's extend our class hierarchy to add a new type, named ChequePayment:
class ChequePayment : Payment {
constructor(amount: BigDecimal, name: String, bankId: String) : super(amount) {
Since we have chosen to avoid the primary constructor, the definition of a secondary constructor has to call the parent one. This call needs to be the first thing our constructor does. Hence, the body of our constructor is preceded by super(args1,args2...). This is different from Java, where we would have moved this call as the first line in our constructor body.
In this example we inherit from one class only – as we said already we can't inherit from more than one class. However, we can inherit from multiple interfaces at the same time.
Let's take a simple example of an amphibious car: it is a boat as well as a car. If you were to model this, we would consider having two interfaces: Drivable and Sailable. And we would have our amphibious car extend both of them:
interface Drivable {
class AmphibiousCar(val name: String) : Drivable, Sailable { override fun drive() {
Remember our class automatically derives from Any; it is as if we had written class AmphibiousCar(val name:String):Any, Drivable, Sailable. When we inherit an interface, we have to provide an implementation for all its methods and properties or we have to make the class abstract. We will talk shortly about abstract classes. There is no restriction on how many interfaces you can inherit from and the order in which you want to specify them. Unlike Java, if you inherit from a class and one or more interfaces, you don't need to list the class as the first entry in the list of parents:
interface IPersistable {
fun save(stream: InputStream) }
interface IPrintable { fun print()
}
abstract class Document(val title: String)
class TextDocument(title: String) : IPersistable, Document(title), IPrintable {
override fun save(stream: InputStream) { println("Saving to input stream") }
override fun print() {
println("Document name:$title") }
}
Visibility modifiers
When you define your class, the contained methods, properties, or fields can have various visibility levels. In Kotlin, there are four possible values:
Public: This can be accessed from anywhere
Internal: This can only be accessed from the module code
Protected: This can only be accessed from the class defining it and any derived classes
Private: This can only be accessed from the scope of the class defining it
If the parent class specifies that a given field is open for being redefined (overwritten), the derived class will be able to modify the visibility level. Here is an example:
open class Container {
protected open val fieldA: String = "Some value"
}
class DerivedContainer : Container() {
public override val fieldA: String = "Something else"
}
Now in the main class, you can create a new DerivedContainer instance and print out the value of fieldA. Yes, this field is now public to any code:
val derivedContainer = DerivedContainer()
println("DerivedContainer.fieldA:${derivedContainer.fieldA}") /*val container:Container =
derivedContainerprintln("fieldA:${container.fieldA}")*/
I commented out the code where we use derivedContainer as if it was an instance of DerivedContainer. If that is the case, trying to compile the commented code will yield an error because fieldA is not accessible.
Redefining the field doesn't mean it will replace the existing one when it comes to object allocation. Remember, a derived class inherits all the parent class fields. It takes just a little bit of code to prove this:
derivedContainer.javaClass.superclass.getDeclaredFields().forEach { field->
field.setAccessible(true)
println("Field:${field.name},${Modifier.toString(field.modifiers)} , Value=${field.get(derivedContainer)}")
}
derivedContainer.javaClass.getDeclaredFields().forEach { field->
field.setAccessible(true)
println("Field:${field.name},${Modifier.toString(field.modifiers)} , Value=${field.get(derivedContainer)}")
}
Run the preceding code and it will print fieldA twice in the output; the first entry will come from the parent class and will be “Some Value”, and the latter will come from the derived class and will read “Something else”.
A typical use case would be to widen the access for a given field, method, and/or property.
But you should be careful about using this since it might break the Liskov substitution principle. Following this principle, if a program is using a base class, then the reference to the base class can be replaced with a derived class without affecting the functionality of the program.