Why open keyword is required for inheritance in Kotlin - Why It Works This Way

Overview - Why open keyword is required for inheritance

What is it?

In Kotlin, classes and methods are final by default, meaning they cannot be inherited or overridden. The open keyword is used to mark a class or method as inheritable or overridable. Without open, you cannot create a subclass from a class or override its functions. This design helps prevent accidental inheritance and makes code safer and clearer.

Why it matters

Without the open keyword, developers might unintentionally extend or change classes, leading to bugs and unpredictable behavior. By requiring open explicitly, Kotlin encourages safer design and clearer intentions. This reduces errors in large projects and makes code easier to maintain and understand.

Where it fits

Before learning about the open keyword, you should understand basic class and inheritance concepts. After this, you can explore advanced inheritance features like abstract classes, interfaces, and sealed classes in Kotlin.

Mental Model

Core Idea

In Kotlin, you must explicitly say a class or method is open to allow inheritance or overriding, making safety the default.

Think of it like...

Think of a locked door in a house. By default, the door is locked (final), so no one can enter (inherit). Using the open keyword is like unlocking the door, allowing others to come in and make changes.

┌───────────────┐
│   Class A     │  (final by default)
│  [locked]     │
└──────┬────────┘
       │ open keyword unlocks
       ▼
┌───────────────┐
│  Class B      │  (inherits Class A)
│  [unlocked]   │

Build-Up - 6 Steps

1

Foundation

Classes are final by default

Concept: Kotlin classes cannot be inherited unless marked open.

In Kotlin, if you write a class like this: class Animal { fun sound() = "Some sound" } Trying to inherit it like this will cause an error: class Dog : Animal() {} The compiler says: "Cannot inherit from final class Animal".

Result

You get a compiler error preventing inheritance.

Understanding that classes are final by default helps you see why inheritance needs explicit permission.

2

Foundation

Open keyword unlocks inheritance

Concept: Marking a class with open allows other classes to inherit it.

If you want to allow inheritance, you write: open class Animal { fun sound() = "Some sound" } class Dog : Animal() {} Now, Dog can inherit from Animal without errors.

Result

The subclass compiles and inherits properties and methods.

Knowing that open explicitly allows inheritance makes your code intentions clear.

3

Intermediate

Open keyword for methods and properties

Concept: Not only classes but also methods and properties must be open to be overridden.

By default, methods are final too: open class Animal { fun sound() = "Some sound" } class Dog : Animal() { override fun sound() = "Bark" // Error: sound is final } To fix this, mark the method open: open class Animal { open fun sound() = "Some sound" } class Dog : Animal() { override fun sound() = "Bark" }

Result

You can override methods only if they are open.

Understanding that open applies to both classes and members prevents accidental overrides.

4

Intermediate

Why final by default improves safety

🤔Before reading on: Do you think making classes final by default helps or hinders code safety? Commit to your answer.

Concept: Final by default prevents unintended inheritance and overrides, reducing bugs.

If all classes were open by default, developers might accidentally extend or override behavior, causing unexpected bugs. Kotlin's design forces you to think about inheritance explicitly, making your code safer and easier to maintain.

Result

Codebases become more predictable and less error-prone.

Knowing the safety benefits explains why Kotlin chose this design, helping you write more robust code.

5

Advanced

Open keyword and performance implications

🤔Before reading on: Does marking a class open affect runtime performance? Commit to your answer.

Concept: Open classes can affect performance because of virtual method calls.

When a class or method is open, the compiler uses virtual dispatch to allow overriding. This can be slightly slower than final classes where calls are direct. Kotlin encourages final by default to allow better optimizations.

Result

Final classes can be optimized better by the compiler.

Understanding performance trade-offs helps you decide when to use open for inheritance.

6

Expert

Open keyword and Kotlin's design philosophy

🤔Before reading on: Do you think Kotlin's open keyword was inspired by Java or designed independently? Commit to your answer.

Concept: Kotlin's open keyword reflects a deliberate design choice to improve safety over Java's default open classes.

Java classes are open by default, which can lead to fragile base class problems. Kotlin chose final by default and requires open to make inheritance explicit. This reduces bugs and clarifies developer intent. It also aligns with Kotlin's goal of safer, more readable code.

Result

Kotlin codebases tend to be safer and clearer about inheritance.

Knowing the historical and design reasons behind open deepens your appreciation of Kotlin's safety features.

Under the Hood

Kotlin compiler marks classes and methods as final by default, preventing subclassing and overriding. When you add open, the compiler generates bytecode that allows virtual dispatch, enabling subclasses to override methods. This changes how method calls are resolved at runtime, using a virtual method table instead of direct calls.

Why designed this way?

Kotlin was designed to fix common problems in Java, such as accidental inheritance and fragile base classes. By making classes final by default, Kotlin forces developers to be explicit about inheritance, improving code safety and maintainability. This design reduces bugs caused by unintended overrides and clarifies developer intent.

┌───────────────┐
│ Kotlin Source │
│ class Animal  │
│ (final by def)│
└──────┬────────┘
       │ compile
       ▼
┌───────────────┐
│ JVM Bytecode  │
│ final class   │
│ no virtual    │
│ dispatch      │
└──────┬────────┘
       │ if open
       ▼
┌───────────────┐
│ JVM Bytecode  │
│ open class    │
│ virtual calls │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think all Kotlin classes can be inherited by default? Commit to yes or no.

Common Belief: All Kotlin classes are open for inheritance by default, like in Java.

Reality: Kotlin classes are final by default and require the open keyword to allow inheritance.

Why it matters: Assuming classes are open leads to compiler errors and confusion when trying to inherit.

Quick: Can you override any method in Kotlin without marking it open? Commit to yes or no.

Common Belief: You can override any method in a subclass without restrictions.

Reality: Only methods marked open (or abstract) can be overridden in subclasses.

Why it matters: Trying to override non-open methods causes errors and misunderstanding of Kotlin's safety model.

Quick: Does marking a class open guarantee better performance? Commit to yes or no.

Common Belief: Open classes always perform better because they are more flexible.

Reality: Open classes can have slightly worse performance due to virtual method dispatch overhead.

Why it matters: Ignoring performance implications can lead to inefficient code in performance-critical applications.

Quick: Is the open keyword a Kotlin feature copied directly from Java? Commit to yes or no.

Common Belief: The open keyword is just like Java's default open classes.

Reality: Kotlin introduced open to explicitly require inheritance permission, unlike Java's default open classes.

Why it matters: Misunderstanding this leads to incorrect assumptions about Kotlin's safety and design philosophy.

Expert Zone

1

Open applies not only to classes but also to individual methods and properties, allowing fine-grained control over inheritance.

2

Using open affects JVM bytecode generation, enabling virtual dispatch which can impact performance subtly.

3

Kotlin's sealed classes complement open by restricting inheritance to a known set of subclasses, balancing flexibility and safety.

When NOT to use

Avoid using open when you want to enforce immutability or strict API contracts. Instead, use final classes or sealed classes to restrict inheritance. For interfaces or abstract behavior, prefer interfaces or abstract classes over open classes.

Production Patterns

In production, developers mark only base classes meant for extension as open, keeping most classes final for safety. Libraries often use open for extension points but keep internal classes final. Sealed classes are used for controlled inheritance hierarchies, such as representing state machines or result types.

Connections

Final keyword in Java

Opposite default behavior

Understanding Kotlin's open keyword is easier when compared to Java's final keyword, which explicitly prevents inheritance, while Kotlin reverses this by making final the default.

Access control in object-oriented programming

Both control how code can be extended or accessed

Open keyword is part of Kotlin's access control strategy, similar to private or protected modifiers, shaping how classes and methods can be used or extended.

Lock and key security systems

Metaphor for controlled access

Just like locks control who can enter a room, the open keyword controls which classes can be extended, enforcing intentional access.

Common Pitfalls

#1 Trying to inherit from a class without open keyword

Wrong approach:

class Dog : Animal() {}

class Animal {} // missing open keyword here

Correct approach:

open class Animal {}

class Dog : Animal() {}

Root cause:

Misunderstanding that classes are final by default in Kotlin.

#2 Overriding a method not marked open

Wrong approach:

open class Animal {
fun sound() = "Some sound"
}

class Dog : Animal() {
override fun sound() = "Bark" // Error
}

Correct approach:

open class Animal {
open fun sound() = "Some sound"
}

class Dog : Animal() {
override fun sound() = "Bark"
}

Root cause:

Not marking methods as open to allow overriding.

#3 Marking everything open without need

Wrong approach:

open class Animal {}
open class Dog : Animal() {}
open class Cat : Animal() {}

Correct approach:

open class Animal {}
class Dog : Animal() {}
class Cat : Animal() {}

Root cause:

Overusing open reduces safety and can cause maintenance issues.

Key Takeaways

Kotlin classes and methods are final by default to prevent accidental inheritance and overriding.

The open keyword explicitly allows inheritance or method overriding, making intentions clear.

This design improves code safety, maintainability, and can enable compiler optimizations.

Understanding when and how to use open helps write robust and clear Kotlin code.

Misusing open or ignoring its rules leads to compiler errors or unsafe code practices.