Implementing Complicated Interfaces with Multiple Overridden Methods in Kotlin

Kotlin is a statically typed, general-purpose programming language developed by JetBrains, that has built world-class IDEs like IntelliJ IDEA, PhpStorm, Appcode, etc. It was first introduced by JetBrains in 2011 and is a new language for the JVM. Kotlin is an object-oriented language, and a “better language” than Java, but still be fully interoperable with Java code. In this article, we are going to discuss How to implement complicated interfaces with multiple overridden methods in Kotlin but before that, you should know something better understanding.

SOLID Principles

SOLID is a mnemonic acronym that is used to define the five basic object-oriented design principles:

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

The Interface Segregation Principle(ISP) states that if an interface becomes too long, it is better to split it into smaller pieces (interfaces) so that the client doesn't need to implement the ones in which they are not interested. In this article, we will understand what and why this is important.

Example

Let's see an example where ISP can help us:

This is a simple example of a "fat" interface:

As you can see, the problem with a big interface is that we are forced to implement the methods even if we don't have anything to do it there. A simple solution is to break that interface into smaller interfaces, like the following code:

Note that now we have divided the one big interface into smaller ones, which can be implemented independently. Kotlin also has a powerful feature that allows you to write the full implementation of methods in the interfaces themselves. Let's take a look at the following code to understand it:

As you can see, we implemented the whole method in the interface, and we were able to call it from the class that implemented that interface. This feature can also be used to follow the ISP principle, as we can put a commonly used method in the interfaces itself; as a result, we will not need to implement it every time we implement that interface.