Dive into Object-Oriented Programming with Kotlin

When studying to jot down Kotlin for the primary time, you aren’t simply studying how one can string collectively advanced chains of seemingly arcane symbols, you might be truly studying how one can symbolize issues in a method for the pc to grasp. But, individuals want to grasp the code as properly. But, what’s “good” code?

All through the years, sure patterns and methods have advanced within the developer group. A few of these ideas have been included instantly right into a language whereas different methods and greatest practices are used at the side of these language options. Because of this, understanding how one can construction and write your code is simply as essential as studying the syntax and key phrases.

On this article, Emmanuel covers the ideas of summary lessons and interfaces in Kotlin. You’ll learn the way and why to make use of these language constructs in your individual code. Within the course of, you’ll achieve a preview of Kodeco’s Object-Oriented Programming with Kotlin course.

Summary Courses

Typically, you might need to stop a category from being instantiated however nonetheless be capable to be inherited from. This can allow you to outline properties and habits widespread to all subclasses. Such a mother or father class is known as an summary class. These lessons can’t be instantiated, which means you possibly can’t create an object of an summary class. You possibly can consider these lessons as templates for different lessons: simply base fashion, configurations, and performance pointers for a selected design. The template can’t run instantly in your app. As an alternative, your app could make use of the template.

Courses declared with the summary key phrase are open by default and might be inherited from. In summary lessons, you too can declare summary strategies marked with summary that don’t have any physique. The summary strategies should be overridden in subclasses. Because the major motive for summary lessons is for different lessons to increase them, they will’t be non-public or remaining. Although, their strategies and properties are remaining by default, until you make them summary, which makes them open for overriding.

Check out this:

summary class Animal {
  summary val identify: String // Summary Property
}

summary class Mammal(val birthDate: String): Animal() { // Non-Summary Property (birthDate)
  summary enjoyable consumeFood() // Summary Methodology

  summary val furColor: Record<String> // Summary Property

  // Non-Summary Methodology
  enjoyable someMammalMethod() {
    println("Non summary operate")
  }
}

class Human(birthDate: String): Mammal(birthDate) {
  // Summary Property (Should be overridden by Subclasses)
  override val identify = "Human"

  // Summary Property (Should be overridden by Subclasses)
  override val furColor = listOf("brown", "black")

  // Summary Methodology (Should be carried out by Subclasses)
  override enjoyable consumeFood() {
    // ...
  }

  // Member technique created by this class (Not Inherited)
  enjoyable createBirthCertificate() {
    // ...
  }
}

Right here, you may have Animal and Mammal lessons, that are each summary, and the Mammal class inherits from Animal. We even have the Human class which inherits from Mammal.

It would appear like quite a bit is going on within the code above, nevertheless it’s less complicated than you assume. Right here’s the breakdown:

1. The Animal class is an summary class that has one summary property; identify. Because of this the subclasses should override it.
2. Subsequent, you may have the Mammal summary class that extends the Animal class, which signifies that Mammal is-a Animal.
   • It has a combination of each summary and non-abstract members. Summary lessons can have non-abstract members.
   • The identify property from the Animal mother or father class isn’t overridden right here. However that’s okay—Mammal is an summary class too, so it simply signifies that identify should be carried out someplace down the road within the inheritance tree. In any other case, you’ll get an error.
3. The Human class extends the Mammal class, which signifies that Human is-a Mammal.
   • It overrides the identify property from the Animal class, which was handed down by Mammal.
   • It additionally overrides Mammal summary members and creates its personal createBirthCertificate() technique.

Now, see what occurs while you attempt to create an occasion of every of those:

val human = Human("1/1/2000")
val mammal = Mammal("1/1/2000") // Error: Can not create an occasion of an summary class

Keep in mind, summary lessons can’t be instantiated, and that’s why attempting to instantiate Mammal causes an error.

Now, summary lessons are cool, however Kotlin doesn’t help a number of inheritance. Because of this a category can solely lengthen one mother or father class. So, a category can solely have one is-a relationship. This generally is a bit limiting relying on what you need to obtain. This leads us to the subsequent assemble, “Interfaces.”

Utilizing Interfaces

To date, you’ve been working with the customized kind, Class. You’ve realized about inheritance and the way a category can lengthen an summary and non-abstract class which are associated. One other very helpful customized kind is Interfaces.

Interfaces merely create a contract that different lessons can implement. Keep in mind, you imagined summary lessons as web site or cell templates above, and this implies we are able to’t use multiple template for the app on the identical time. Interfaces might be seen as plugins or add-ons which add a function or habits to the app. An app can have just one template however can have a number of plugins related to it.

A category can implement a number of interfaces, however the lessons that implement them should not be associated. You possibly can say that interfaces exhibit the is relationship somewhat than the is-a relationship. One other factor to notice is that almost all interfaces are named as adjectives, though this isn’t a rule. For instance, Pluggable, Comparable, Drivable. So you can say a Tv class is Pluggable or a Automobile class is Drivable. Keep in mind, a category can implement a number of interfaces, so the Automobile class might be Drivable and on the identical time Chargeable if it’s an electrical automobile. Identical factor with a Cellphone is Chargeable despite the fact that Automobile and Cellphone are unrelated.

Now, think about you may have two lessons Microwave and WashingMachine. These are completely different electrical home equipment, however they’ve one factor in widespread, they each must be related to electrical energy to operate. Units that connect with electrical energy all the time have some essential issues in widespread. Let’s push these commonalities to an interface.

Check out how you can do that:

interface Pluggable {

  // properties in interfaces can not keep state
  val neededWattToWork: Int 
  
  // this would possibly not work. would lead to an error due to the explanation above
  // val neededWattToWork: Int = 40 

  //Measured in Watt
  enjoyable electricityConsumed(wattLimit: Int) : Int

  enjoyable turnOff()

  enjoyable turnOn()
}

class Microwave : Pluggable {

  override val neededWattToWork = 15

  override enjoyable electricityConsumed(wattLimit: Int): Int {
    return if (neededWattToWork > wattLimit) {
      turnOff()
      0
    } else {
      turnOn()
      neededWattToWork
    }
  }

  override enjoyable turnOff() {
    println("Microwave Turning off...")
  }

  override enjoyable turnOn() {
    println("Microwave Turning on...")
  }
}

class WashingMachine : Pluggable {

  override val neededWattToWork = 60

  override enjoyable electricityConsumed(wattLimit: Int): Int {
    return if (neededWattToWork > wattLimit) {
      turnOff()
      0
    } else {
      turnOn()
      neededWattToWork
    }
  }

  override enjoyable turnOff() {
    println("WashingMachine Turning off...")
  }

  override enjoyable turnOn() {
    println("WashingMachine Turning on...")
  }
}

You possibly can see that the Pluggable interface creates a contract that every one lessons implementing it should comply with. The members of the interface are summary by default, so that they should be overridden by subclasses.

Observe: Properties in interfaces can’t keep their state, so initializing it might lead to an error.

Additionally, interfaces can have default technique implementation. So turnOn might have a physique like so:

enjoyable turnOn() {
  println("Turning on...")
}

Let’s say the WashingMachine subclass doesn’t override it. Then you may have one thing like this:

val washingMachine = WashingMachine()
washingMachine.turnOn() // Turning on...

The output will likely be “Turning on…” as a result of it was not overridden within the WashingMachine class.

When an interface defines a default implementation, you possibly can nonetheless override the implementation in a category that implements the interface.