Dive into Object-Oriented Programming with Kotlin

When studying to put in writing Kotlin for the primary time, you aren’t simply studying tips on how to string collectively advanced chains of seemingly arcane symbols, you might be really studying tips on how to signify issues in a manner for the pc to know. But, individuals want to know the code as properly. But, what’s “good” code?

All through the years, sure patterns and strategies have advanced within the developer group. A few of these ideas have been integrated immediately right into a language whereas different strategies and greatest practices are used along side these language options. For that reason, understanding tips on how to construction and write your code is simply as essential as studying the syntax and key phrases.

Within the following excerpt, Emmanuel Okiche 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 personal code. Within the course of, you’ll acquire a preview of Kodeco’s Object-Oriented Programming with Kotlin course.

Summary Courses

Typically, chances are you’ll wish to stop a category from being instantiated however nonetheless have the ability to be inherited from. It will allow you to outline properties and conduct frequent to all subclasses. Such a mum or dad class is known as an summary class. These lessons can’t be instantiated, which means you’ll be able to’t create an object of an summary class. You possibly can consider these lessons as templates for different lessons: simply base type, configurations, and performance tips for a selected design. The template can’t run immediately 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 could be inherited from. In summary lessons, you may as well declare summary strategies marked with summary that haven’t any physique. The summary strategies have to be overridden in subclasses. For the reason that foremost cause for summary lessons is for different lessons to increase them, they’ll’t be personal or remaining. Although, their strategies and properties are remaining by default, except you make them summary, which makes them open for overriding.

Check out this:

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

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

  summary val furColor: Record // Summary Property

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

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

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

  // Summary Methodology (Have to be applied by Subclasses)
  override enjoyable consumeFood() {
    // ...
  }

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

Right here, you’ve got 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’d seem like lots is going on within the code above, nevertheless it’s less complicated than you suppose. Right here’s the breakdown:

1. The Animal class is an summary class that has one summary property; title. Which means the subclasses should override it.
2. Subsequent, you’ve got the Mammal summary class that extends the Animal class, which implies that Mammal is-a Animal.
   • It has a combination of each summary and non-abstract members. Summary lessons can have non-abstract members.
   • The title property from the Animal mum or dad class isn’t overridden right here. However that’s okay—Mammal is an summary class too, so it simply implies that title have to be applied 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 implies that Human is-a Mammal.
   • It overrides the title 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 once 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

Bear 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 assist a number of inheritance. Which means a category can solely prolong one mum or dad class. So, a category can solely have one is-a relationship. This is usually a bit limiting relying on what you wish to obtain. This leads us to the subsequent assemble, “Interfaces.”

Utilizing Interfaces

Up to now, you’ve been working with the customized sort, Class. You’ve realized about inheritance and the way a category can prolong an summary and non-abstract class which can be associated. One other very helpful customized sort is Interfaces.

Interfaces merely create a contract that different lessons can implement. Bear in mind, you imagined summary lessons as web site or cellular templates above, and this implies we will’t use multiple template for the app on the similar time. Interfaces could be seen as plugins or add-ons which add a function or conduct to the app. An app can have just one template however can have a number of plugins linked to it.

A category can implement a number of interfaces, however the lessons that implement them should not be associated. You would say that interfaces exhibit the is relationship fairly than the is-a relationship. One other factor to notice is that the majority interfaces are named as adjectives, though this isn’t a rule. For instance, Pluggable, Comparable, Drivable. So you may say a Tv class is Pluggable or a Automobile class is Drivable. Bear in mind, a category can implement a number of interfaces, so the Automobile class could be Drivable and on the similar time Chargeable if it’s an electrical automotive. Similar factor with a Telephone is Chargeable though Automobile and Telephone are unrelated.

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

Check out how you may do that:

interface Pluggable {

  // properties in interfaces can not preserve state
  val neededWattToWork: Int 
  
  // this would possibly not work. would end in 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 each one lessons implementing it should comply with. The members of the interface are summary by default, so that they have to be overridden by subclasses.

Word: Properties in interfaces can’t preserve their state, so initializing it could end in 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’ve got one thing like this:

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

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

When an interface defines a default implementation, you’ll be able to nonetheless override the implementation in a category that implements the interface.