skip to content

Inside an `open class`, is a regular method automatically overridable? Explain how `open` applies to members versus the class itself.

level: middleimportance: must knowfreq 70%

answer

  1. open class != open members
  2. Each member final unless its own open
  3. Override is open downstream; use final override to stop
  4. Interface/abstract members implicitly open
  5. open member in final class = error

basics

~10 s

No. Marking the class open only allows subclassing. Each method or property is still final and must be marked open separately to be overridable.

solid answer

~40 s

`open` is granular. On a class it permits inheritance; on a member it permits overriding — the two are independent. In an `open class`, every function and property is final by default, so a subclass cannot override it unless it is individually declared `open`. You therefore need `open class Foo { open fun bar() }` to override `bar`. There are implicit cases: `abstract` members are implicitly open; members declared in an `interface` are open by default; and a member that *overrides* an open member is itself open downstream unless you re-close it with `final override`. You cannot make a member open inside a final class — the compiler rejects an open member in a class that isn't open/abstract, because there could never be a subclass to override it.

code

kotlin · 8 lines
kotlin
open class Repo {
    fun save() {}
    open fun load() {}
}
class CachingRepo : Repo() {
    override fun load() {}
    // override fun save() {} // ERROR: save is final
}

go deeper

for a junior

Recognizes that members need their own open even in an open class.

for a middle

Explains class-vs-member granularity and the implicit-open cases (interface/abstract).

for a senior

Knows overrides are open by default and uses final override deliberately to control the hierarchy.

for a principal

Discusses designing extension points (template-method hooks) while keeping the rest sealed for API stability.

## Two independent switches `open` controls two distinct things depending on where it sits: 1. **On a class** → "you may subclass me." 2. **On a member** (function or property) → "you may override me." Making the class open does **not** propagate to its members. Each member is final by default: ```kotlin open class Repo { fun save() {} // final - cannot be overridden open fun load() {} // open - can be overridden open val cacheTtl = 60 // open property } class CachingRepo : Repo() { // override fun save() {} // ERROR: save is final override fun load() {} // OK override val cacheTtl = 300 // OK } ``` ## Implicit-open cases You do NOT write `open` when it would be redundant: - **interface** members are open by default (overridable in implementers). - **abstract** members are implicitly open (they *must* be overridden). ## Overrides are open by default — and how to stop that When you `override` an open member, your override is itself **open** for further subclasses. To stop the chain, prefix with `final`: ```kotlin open class B { open fun f() {} } open class C : B() { final override fun f() {} } // grandchildren can't override f ``` ## You can't open a member of a final class An `open` member only makes sense if a subclass could exist. Declaring an open member inside a plain `final class` is a compile error: ```kotlin class Closed { // open fun g() {} // ERROR: 'open' has no effect in a final class } ``` ## Properties The same rules apply to `val`/`var`. An open `val` can be overridden by a `val` or `var`; an open `var` must be overridden by a `var`. Backing-field and custom-getter nuances follow the same open/final gate. ## Why granular? Granularity lets an author expose a few extension points (template-method hooks) while keeping the rest of the class's behavior locked and stable — minimizing the fragile-base-class surface.

  • If a subclass overrides an open method, can the subclass's grandchild override it again?
    Yes — an override is implicitly open. To prevent it, declare the override as `final override`.
  • Why does the compiler reject `open fun` inside a final class?
    No subclass can exist for a final class, so an open member could never be overridden; the modifier is meaningless and flagged as an error.

saying these in an interview costs you the question

  • Believing `open class` makes all methods overridable
  • Not knowing overrides are open by default
  • Unaware of `final override` to seal a method mid-hierarchy
  • Thinking you must write `open` on interface members

context

resolving links…