Inheritance & Interfaces

Both interfaces give a body for the same method, so Kotlin can't pick one for you. You must override the method in your class. Otherwise the compiler reports an error and refuses to build.

Yes. A Kotlin interface method can include a body. Classes that implement the interface inherit that body for free and only need to override it if they want different behavior.

No. By default Kotlin classes are final, so you cannot extend them. To allow subclassing you mark the class with the open keyword.

You must write override before a function or property that replaces one from the parent. It makes your intent explicit. If you forget it, the code does not compile.

In Kotlin everything is closed for inheritance unless you open it. Marking something abstract automatically makes it open, because an abstract member with no body only makes sense if subclasses can override it.

Use super<TypeName>.method(). The name in angle brackets is the exact parent whose version you want to run. You can call several parents this way, in any order, from inside your override.

An interface property has no stored value—no backing field. It can be abstract (the class must provide it) or it can define a getter that computes a value from other members.

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

Inside an overriding function, write super.functionName(args) to run the parent's version. It is useful when you want to extend the parent behavior rather than fully replace it.

You're forced to override only when more than one parent supplies a body for the same method. If only one parent has a body (or none do for an abstract member you must implement anyway), there's no conflict to resolve.

A class can list several interfaces after the colon, separated by commas, and must satisfy all of them. It then counts as each of those types, so it can be passed wherever any one of them is expected.

Mark the parent property open, then redeclare it with override val/override var. You may override a val with a var (adding a setter), but not a var with a val.

Yes. An abstract subclass can override an inherited open method and re-declare it as abstract, removing the inherited implementation and forcing its own subclasses to supply a new one.

Choose an abstract class when you need shared stored state, a constructor, or want to allow only one parent. Choose an interface when you want a contract many unrelated types can implement and combine.

The same rule applies: if two interfaces give a body (a getter) for the same property, you must override it and can pick a parent's getter with super<Type>.prop. Interfaces can't hold real fields, so there's no stored state to clash — only the accessor logic.

Use an interface when you only need behavior contracts and want a type to implement several. Use an abstract class when you need stored state, a constructor, or initialization logic, since interfaces can't hold any of those.

Many frameworks create runtime subclasses (proxies/mocks), which final classes block. Kotlin provides compiler plugins like all-open (and kotlin-spring) that automatically open annotated classes so those tools work.

By default an overriding method stays open, so deeper subclasses can keep overriding it. To stop that, write final override on the method, which seals it.

When you override something, that override can also be overridden by classes below you — it stays open automatically. Write final override to seal it so no further subclass can change it.

Final-by-default protects against accidental inheritance and the fragile base class problem, pushing teams toward composition and interfaces. The trade-off is more friction when frameworks or extension genuinely need subclassing.

Default methods can't store or remember anything because interfaces have no fields. They can only use parameters and call other interface members. To keep state, implementers add their own property, which the interface declares as an abstract property.

When a base class is being constructed, the subclass part isn't set up yet. If the base constructor calls a method the subclass overrides, that override runs before the subclass's fields exist, so it may see uninitialized values or null.

Java default methods behave like Kotlin interface defaults, so the same 'override and qualify' rule applies when a Kotlin class mixes them. In design, use super<Type>.foo() to deliberately combine small reusable behaviors; if conflicts pile up, it's a sign to rethink the hierarchy.

An override may return a more specific subtype than the parent (covariant return). Danger: if a parent constructor calls an open method, the subclass override runs before the subclass's own fields are set, so it may see null/zero values.