Inheritance — Basics

Summary

The provided web content discusses the basics of inheritance in Kotlin, emphasizing that classes and members are closed by default, requiring explicit use of the open keyword for extensibility, and highlighting Kotlin's design principles of immutability and explicitness, with similarities to Java's inheritance model and a note on the execution order of initializers.

Abstract

The article "Inheritance — Basics" on the Kotlin programming language delves into the fundamental aspects of inheritance within Kotlin. It underscores a key design choice in Kotlin where classes and their members are not extensible unless explicitly marked with the open keyword, which contrasts with the open-by-default approach in languages like Java. This design decision is rooted in Kotlin's guiding principles of immutability and explicitness, aiming to encourage better software design and maintainability. The inheritance model in Kotlin is comparable to Java's, with single class inheritance and multiple interface inheritance allowed. The article also touches on the necessity for derived classes to call base class constructors, either directly in the primary constructor or through the super keyword in secondary constructors, and the ability for different secondary constructors to invoke different base class constructors. Readers are encouraged to explore the execution order of initializers in a separate article and to engage with the broader "Kotlin Primer" series for a comprehensive understanding of Kotlin.

Opinions

The author acknowledges the controversial nature of Kotlin's closed-by-default classes and members, noting the strong opinions and debates that surround this design choice.
The author expresses support for Kotlin's closed-by-default approach, viewing it as a reflection of the language's commitment to immutability and explicitness, which are considered fundamental principles guiding Kotlin's design.
The article suggests that the reader should familiarize themselves with arguments from both sides of the debate regarding Kotlin's inheritance design before forming their own opinion.
The recommendation to read the introduction and the table of contents indicates the author's view on the importance of foundational knowledge and the structured approach to learning Kotlin through the "Kotlin Primer" series.

Basic features of inheritance in Kotlin — closed by default, implicit inheritance of Any, with a quick note about the execution order of initializers

— — — — — — — — — — — — — — —

THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.

— — — — — — — — — — — — — — —

Tags: #FYI

This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.

It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.

Probably one of the most controversial design decision in the Kotlin language is the fact that classes (and class members) are closed by default. This means that to be able to extend a class (or override a class member), it must explicitly be marked using the open keyword. Classes (or class members) which are not marked in this way cannot be extended.

There are many rage discussions on why this is so, and if it was a good idea or not. I leave it up to the reader to read up on arguments from both sides and then pick one. For me, it is a reflections of two fundamental principles that guide the design of Kotlin: Immutability and Explicitness.

Other than that, basic inheritance is fairly similar to Java — every class inherits from exactly one class and zero or more interfaces. Multiple inheritance between classes is not allowed.

If the derived class has a primary constructor, a base class constructor must be called in that primary constructor.

If the derived class has no primary constructor, then each secondary constructor has to initialize the base type using the super keyword or it has to delegate to another constructor which does.

Note that in this case different secondary constructors can call different constructors of the base type.