In Kotlin, are classes open for subclassing by default? What do you write to allow a class to be subclassed?
answer
- Final by default (opposite of Java)
- open keyword to allow subclassing
- Members final too, need open each
- Effective Java: design for inheritance or prohibit it
- Interfaces/abstract are implicitly open
basics
~10 sNo. By default Kotlin classes are final, so you cannot extend them. To allow subclassing you mark the class with the open keyword.
solid answer
~40 sKotlin classes are final by default: unlike Java, you cannot inherit from a class unless its author explicitly opts in with the open modifier. Writing `open class Base` makes Base subclassable; without open, `class Child : Base()` fails to compile with an error that Base is final. The same rule applies to members: methods and properties are final by default and need open to be overridable. This is a deliberate language choice — Effective Java's 'design and document for inheritance or else prohibit it' is enforced by the compiler. abstract and sealed classes are implicitly open enough to be extended (abstract is inherently open), and interfaces are always open. Common keywords: `open`, `final` (explicit), `abstract`, `sealed`.
code
kotlin · 6 lines// Without open -> compile error
class Animal
// class Dog : Animal() // ERROR: Animal is final
open class Vehicle
class Car : Vehicle() // OKgo deeper
Knows classes are final by default and open allows subclassing.
Adds that members are independently final and must each be open, and that interfaces/abstract differ.
Explains the design rationale (fragile base class, Effective Java) and contrasts with Java's inverted default.
Frames it as an API-stability/governance decision and discusses ecosystem impact (e.g. mocking frameworks, the all-open plugin).
## The default: final In Kotlin every class is **final** unless you say otherwise. *Final* means it cannot be used as a superclass — no other class may inherit from it. This is the opposite of Java, where classes are open (subclassable) unless you write `final`. ```kotlin class Base // final by default class Child : Base() // ERROR: This type is final, so it cannot be inherited from ``` To permit inheritance, the **author** of the class must opt in with the `open` keyword: ```kotlin open class Base // now subclassable class Child : Base() // OK ``` ## Why this default exists The design follows Joshua Bloch's *Effective Java* item: "Design and document for inheritance or else prohibit it." Allowing inheritance is a real API commitment — subclasses can depend on internal call sequences and break when the parent changes (the *fragile base class* problem). Kotlin makes the safe option (final) the default and forces authors to *consciously* enable extension. ## Members are also final by default The rule extends to functions and properties. Even inside an `open` class, individual methods/properties stay final unless individually marked `open`: ```kotlin open class Service { fun fixed() {} // final: cannot override open fun extendable() {} // can be overridden } ``` ## Where the rule is relaxed - **Interfaces** are always open; their members are open by default (you don't write `open`). - **abstract classes** are implicitly open enough to be extended; `abstract` members are implicitly open. - **sealed classes** are open to a *restricted, compile-time-known* set of subclasses in the same module/package. ## Keywords summary - `open` — explicitly allow inheritance/overriding. - `final` — explicitly forbid (the default; useful to re-close an inherited open member). - `abstract` — must be subclassed; cannot be instantiated.
- How does this differ from Java?Java classes are open by default and you write `final` to lock them; Kotlin inverts this — final by default, `open` to unlock.
- Does open on a class make its methods overridable?No. The class being open only allows subclassing; each method/property is still final unless individually marked open.
A Kotlin class is a locked door by default; open is the key the author chooses to hand out.
saying these in an interview costs you the question
- Saying Kotlin classes are open by default like Java
- Thinking you write `final` to prevent inheritance in normal Kotlin
- Claiming `open` on a class also opens all its members
- Not knowing interfaces are always open