Delegation vs inheritance decision in Kotlin - Trade-offs & Expert Analysis

Overview - Delegation vs inheritance decision

What is it?

Delegation and inheritance are two ways to reuse code in Kotlin. Inheritance means a class takes properties and behaviors from a parent class. Delegation means a class uses another class to do some work for it, passing tasks along. Both help avoid repeating code but work differently.

Why it matters

Without clear rules on when to use delegation or inheritance, code can become messy, hard to change, or buggy. Choosing the right method makes programs easier to understand, maintain, and extend. It also helps avoid problems like tight coupling or unexpected side effects.

Where it fits

Before this, you should know basic Kotlin classes and interfaces. After this, you can learn advanced design patterns and Kotlin's built-in delegation features.

Mental Model

Core Idea

Delegation means handing off tasks to another object, while inheritance means taking tasks from a parent class directly.

Think of it like...

Think of inheritance like inheriting a family recipe book—you get all the recipes your parents had. Delegation is like hiring a chef to cook parts of your meal for you—you ask them to do specific dishes while you handle the rest.

┌───────────────┐          ┌───────────────┐
│   Child       │          │  Delegate     │
│  (inherits)   │─────────▶│  (handles     │
│  Parent class │          │   tasks)      │
└───────────────┘          └───────────────┘

Inheritance: Child class extends Parent class directly.
Delegation: Class holds a reference to Delegate and calls its methods.

Build-Up - 7 Steps

1

Foundation

Understanding inheritance basics

Concept: Inheritance lets a class get properties and functions from a parent class.

In Kotlin, you use the 'open' keyword to allow a class to be inherited. A child class uses ':' to extend the parent. The child can use or override parent functions. Example: open class Animal { fun sound() = "Some sound" } class Dog : Animal() { fun bark() = "Woof" } val dog = Dog() println(dog.sound()) // Output: Some sound println(dog.bark()) // Output: Woof

Result

The Dog class can use the sound() function from Animal and its own bark() function.

Understanding inheritance basics shows how code reuse works by sharing behavior through a class hierarchy.

2

Foundation

Understanding delegation basics

Concept: Delegation means a class uses another class to perform some tasks instead of inheriting them.

In Kotlin, delegation can be manual by holding a reference to another class and calling its methods. Example: interface SoundMaker { fun sound(): String } class Animal : SoundMaker { override fun sound() = "Some sound" } class Dog(private val animal: SoundMaker) : SoundMaker by animal { fun bark() = "Woof" } val animal = Animal() val dog = Dog(animal) println(dog.sound()) // Output: Some sound println(dog.bark()) // Output: Woof

Result

Dog delegates the sound() call to the Animal instance it holds.

Knowing delegation basics reveals how classes can share behavior without a strict parent-child relationship.

3

Intermediate

Comparing coupling in inheritance and delegation

🤔Before reading on: do you think inheritance or delegation creates tighter coupling? Commit to your answer.

Concept: Inheritance creates a strong link between child and parent, while delegation keeps classes more independent.

Inheritance means the child class depends directly on the parent class structure. Changes in the parent can break the child. Delegation uses a separate object, so the main class can change without affecting the delegate. Example: // Inheritance: tightly coupled class Parent { fun greet() = "Hi" } class Child : Parent() {} // Delegation: loosely coupled class Delegate { fun greet() = "Hi" } class Child(private val delegate: Delegate) { fun greet() = delegate.greet() }

Result

Delegation reduces tight coupling, making code easier to change and test.

Understanding coupling differences helps choose delegation to keep code flexible and inheritance when a strong relationship is needed.

4

Intermediate

When to override behavior in inheritance

🤔Before reading on: do you think overriding parent methods is always safe? Commit to your answer.

Concept: Inheritance allows child classes to change parent behavior by overriding methods, but this can cause unexpected bugs if not done carefully.

In Kotlin, you override a parent method with 'override'. If the child changes behavior too much, it can break assumptions made by code using the parent. Example: open class Animal { open fun sound() = "Some sound" } class Dog : Animal() { override fun sound() = "Woof" } val animal: Animal = Dog() println(animal.sound()) // Output: Woof

Result

Overriding lets child classes customize behavior but can cause surprises if the new behavior doesn't match expectations.

Knowing the risks of overriding helps prevent bugs by carefully designing which methods can be changed.

5

Intermediate

Kotlin's built-in delegation feature

Concept: Kotlin supports delegation directly with the 'by' keyword to simplify delegation code.

Instead of writing delegation methods manually, Kotlin lets you delegate interface implementation to another object. Example: interface SoundMaker { fun sound(): String } class Animal : SoundMaker { override fun sound() = "Some sound" } class Dog(animal: SoundMaker) : SoundMaker by animal { fun bark() = "Woof" } val dog = Dog(Animal()) println(dog.sound()) // Output: Some sound println(dog.bark()) // Output: Woof

Result

The Dog class automatically forwards sound() calls to the Animal instance.

Understanding Kotlin's delegation syntax reduces boilerplate and encourages delegation use.

6

Advanced

Choosing delegation to avoid fragile base class problem

🤔Before reading on: do you think inheritance always makes code easier to maintain? Commit to your answer.

Concept: Inheritance can cause the fragile base class problem where changes in the parent break many child classes; delegation avoids this by composition.

When a parent class changes, all child classes might break or behave incorrectly. Delegation keeps classes separate, so changes in one don't ripple unexpectedly. Example: // Fragile inheritance open class Parent { open fun doWork() = "Work" } class Child : Parent() { override fun doWork() = "Child work" } // If Parent changes doWork, Child might break. // Delegation avoids this by using separate objects.

Result

Delegation improves code stability and maintainability in large projects.

Knowing this problem helps developers prefer delegation in complex systems to reduce bugs.

7

Expert

Performance and memory trade-offs in delegation vs inheritance

🤔Before reading on: do you think delegation always costs more memory or time than inheritance? Commit to your answer.

Concept: Delegation can add slight overhead due to extra object references and calls, while inheritance is more direct, but the difference is often negligible.

Inheritance uses a single object with all methods, so calls are direct. Delegation requires holding a reference to another object and forwarding calls, which adds a small cost. However, delegation allows more flexible designs and can avoid complex inheritance hierarchies that hurt performance. In Kotlin, delegation is optimized but still involves an extra object. Example: class Delegate { fun work() = "Done" } class Worker(private val delegate: Delegate) { fun work() = delegate.work() }

Result

Delegation may use slightly more memory and CPU but offers better design flexibility.

Understanding trade-offs helps experts balance performance with maintainability.

Under the Hood

Inheritance works by creating a class hierarchy where child classes share the parent's memory layout and methods. The Kotlin compiler generates bytecode that links child classes to parent methods, allowing method overriding via virtual calls. Delegation works by holding a reference to another object and forwarding method calls to it. Kotlin's 'by' keyword generates these forwarding methods automatically, reducing boilerplate.

Why designed this way?

Inheritance was the traditional way to reuse code in object-oriented languages, reflecting real-world 'is-a' relationships. However, it can cause tight coupling and fragile designs. Delegation was introduced to promote composition over inheritance, allowing more flexible and modular designs. Kotlin added built-in delegation to make this pattern easier and less error-prone.

Inheritance:
┌───────────────┐
│   Parent      │
│  (methods)    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│   Child       │
│ inherits from │
│   Parent      │
└───────────────┘

Delegation:
┌───────────────┐       holds       ┌───────────────┐
│   Client      │──────────────────▶│   Delegate    │
│  (forwards)   │                   │  (implements) │
└───────────────┘                   └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does delegation always mean more complex code than inheritance? Commit to yes or no.

Common Belief: Delegation is always more complex and harder to understand than inheritance.

Reality: Delegation can simplify code by separating concerns and reducing deep inheritance chains, making code easier to maintain.

Why it matters: Believing delegation is too complex may cause developers to overuse inheritance, leading to fragile and tightly coupled code.

Quick: Does overriding a parent method always improve the child class? Commit to yes or no.

Common Belief: Overriding parent methods in inheritance always makes the child class better.

Reality: Overriding can introduce bugs if the new behavior breaks assumptions made by other code relying on the parent.

Why it matters: Misusing overrides can cause subtle bugs and unexpected behavior in large codebases.

Quick: Is delegation just a fancy way to do inheritance? Commit to yes or no.

Common Belief: Delegation is just inheritance with extra steps.

Reality: Delegation is a different design principle based on composition, promoting loose coupling and flexibility.

Why it matters: Confusing delegation with inheritance can lead to poor design choices and missed benefits of composition.

Quick: Does delegation always have worse performance than inheritance? Commit to yes or no.

Common Belief: Delegation always causes significant performance overhead compared to inheritance.

Reality: Delegation adds minimal overhead, often negligible in real applications, and the design benefits usually outweigh the cost.

Why it matters: Avoiding delegation due to performance fears can prevent better, more maintainable designs.

Expert Zone

1

Delegation allows mixing behaviors from multiple sources without the diamond problem of multiple inheritance.

2

Kotlin's built-in delegation generates bytecode that forwards calls efficiently, avoiding common delegation boilerplate errors.

3

Inheritance can cause hidden dependencies and fragile base classes, which delegation helps to avoid by explicit composition.

When NOT to use

Avoid inheritance when you need flexible, changeable behavior or want to combine multiple behaviors. Use delegation or interfaces instead. Inheritance is best when there is a clear 'is-a' relationship and stable base behavior.

Production Patterns

In production Kotlin code, delegation is often used for implementing interfaces by forwarding to helper classes, enabling easier testing and swapping implementations. Inheritance is used for stable hierarchies like UI components or domain models where behavior is shared and extended.

Connections

Composition over inheritance principle

Delegation is a direct application of this principle, promoting composition instead of class hierarchies.

Understanding delegation clarifies why composition is often preferred for flexible and maintainable code.

Design patterns: Strategy pattern

Delegation enables the Strategy pattern by allowing behavior to be selected and changed at runtime via delegation.

Knowing delegation helps implement flexible algorithms and behaviors in software design.

Organizational management

Delegation in programming mirrors task delegation in management, where a manager assigns tasks to team members rather than doing everything themselves.

Seeing delegation as a management style helps understand its benefits in distributing responsibilities and improving flexibility.

Common Pitfalls

#1 Overusing inheritance for code reuse leads to fragile, tightly coupled code.

Wrong approach:

open class Vehicle {
open fun start() = "Starting"
}

class Car : Vehicle() {
override fun start() = "Car starting"
}

class ElectricCar : Car() {
override fun start() = "Electric car starting silently"
}

// Deep inheritance chain with overrides

Correct approach:

interface Starter {
fun start(): String
}

class Vehicle : Starter {
override fun start() = "Starting"
}

class Car(private val starter: Starter) : Starter by starter {
fun drive() = "Driving"
}

class ElectricCar(private val starter: Starter) : Starter by starter {
fun charge() = "Charging"
}

// Use delegation to share start behavior

Root cause:

Misunderstanding inheritance as the only way to share code causes deep, fragile hierarchies.

#2 Overriding parent methods without preserving contracts causes bugs.

Wrong approach:

open class Printer {
open fun print() = "Printing"
}

class BrokenPrinter : Printer() {
override fun print() = throw Exception("Failed")
}

// Code expecting print() to succeed breaks

Correct approach:

open class Printer {
open fun print() = "Printing"
}

class SafePrinter : Printer() {
override fun print() = "Safe printing"
}

// Overrides preserve expected behavior

Root cause:

Ignoring behavioral contracts when overriding methods leads to unexpected failures.

#3 Manually writing delegation methods causes boilerplate and errors.

Wrong approach:

class Wrapper(private val list: List) {
fun size() = list.size
fun get(index: Int) = list[index]
fun isEmpty() = list.isEmpty()
// Many more methods duplicated
}

Correct approach:

class Wrapper(private val list: List) : List by list {
// Delegation automatically forwards all List methods
}

Root cause:

Not using Kotlin's built-in delegation leads to repetitive code and mistakes.

Key Takeaways

Inheritance shares behavior by creating a parent-child class relationship, but can cause tight coupling and fragile code.

Delegation shares behavior by having one class use another to perform tasks, promoting loose coupling and flexibility.

Kotlin supports delegation natively with the 'by' keyword, reducing boilerplate and encouraging composition.

Choosing delegation over inheritance helps avoid common problems like the fragile base class and complex hierarchies.

Understanding the trade-offs and design principles behind delegation and inheritance leads to better, maintainable Kotlin code.

Practice

1. Which statement best describes when to use inheritance in Kotlin?

easy

A. When you want to hide implementation details completely.

B. When you want to reuse code without creating a parent-child relationship.

C. When a class is a specialized type of another class ("is-a" relationship).

D. When you want to avoid any relationship between classes.

Solution

1. Step 1: Understand inheritance purpose

   Inheritance models an "is-a" relationship where a subclass extends a superclass.

2. Step 2: Match the correct use case

   Using inheritance is appropriate when a class is a specialized version of another class.

3. Final Answer:

   When a class is a specialized type of another class ("is-a" relationship). -> Option C

4. Quick Check:

   Inheritance = "is-a" relationship [OK]

Hint: Use inheritance for clear "is-a" relationships [OK]

Common Mistakes:

• Confusing delegation with inheritance
• Using inheritance for code reuse only
• Thinking inheritance hides implementation

2. Which Kotlin syntax correctly shows delegation of interface Printer by class Document?

easy

A. class Document : Printer(printer)

B. class Document(val printer: Printer) : Printer by printer

C. class Document : Printer implements printer

D. class Document(printer: Printer) extends Printer

Solution

1. Step 1: Recall Kotlin delegation syntax

   Kotlin uses : Interface by instance to delegate interface implementation.

2. Step 2: Identify correct syntax

   class Document(val printer: Printer) : Printer by printer correctly shows delegation with class Document(val printer: Printer) : Printer by printer.

3. Final Answer:

   class Document(val printer: Printer) : Printer by printer -> Option B

4. Quick Check:

   Delegation syntax = : Interface by instance [OK]

Hint: Delegation uses ': Interface by instance' syntax [OK]

Common Mistakes:

• Using extends keyword (not Kotlin)
• Writing implements instead of by
• Missing val/var for delegated instance

3. What is the output of this Kotlin code?

interface Logger {
    fun log(message: String)
}

class ConsoleLogger : Logger {
    override fun log(message: String) {
        println("Console: $message")
    }
}

class FileLogger : Logger {
    override fun log(message: String) {
        println("File: $message")
    }
}

class Service(logger: Logger) : Logger by logger

fun main() {
    val service = Service(ConsoleLogger())
    service.log("Start")
}

medium

A. Console: Start

B. File: Start

C. Start

D. Compilation error

Solution

1. Step 1: Understand delegation in Service class

   Service delegates Logger interface to the passed logger instance, here ConsoleLogger.

2. Step 2: Trace the log call

   Calling service.log("Start") calls ConsoleLogger.log, printing "Console: Start".

3. Final Answer:

   Console: Start -> Option A

4. Quick Check:

   Delegation calls ConsoleLogger.log = Console: Start [OK]

Hint: Delegation calls passed instance methods [OK]

Common Mistakes:

• Confusing which logger is used
• Expecting FileLogger output
• Thinking delegation copies methods

4. Identify the error in this Kotlin code using delegation:

interface Worker {
    fun work()
}

class Employee : Worker {
    override fun work() {
        println("Employee working")
    }
}

class Manager(worker: Worker) : Worker by worker {
    fun manage() {
        println("Managing team")
    }
}

fun main() {
    val manager = Manager()
    manager.work()
    manager.manage()
}

medium

A. Manager class missing argument for Worker in constructor call.

B. Employee class does not implement work() method.

C. Delegation syntax is incorrect; should use extends instead of by.

D. manage() method cannot be called on Manager instance.

Solution

1. Step 1: Check Manager constructor usage

   Manager requires a Worker parameter in constructor but none is provided in main().

2. Step 2: Identify compilation error

   Calling Manager() without argument causes a compilation error due to missing parameter.

3. Final Answer:

   Manager class missing argument for Worker in constructor call. -> Option A

4. Quick Check:

   Constructor argument missing = compilation error [OK]

Hint: Check constructor parameters when using delegation [OK]

Common Mistakes:

• Ignoring constructor parameters
• Confusing delegation syntax with inheritance
• Assuming manage() is inaccessible

5. You want to design a Kotlin class SmartDevice that can either behave like a Phone or a Camera depending on user choice at runtime. Which approach is best and why?

hard

A. Use static methods in SmartDevice to mimic Phone and Camera features.

B. Use inheritance with SmartDevice extending Phone or Camera based on a flag.

C. Use multiple inheritance to inherit both Phone and Camera directly.

D. Use delegation to delegate Phone or Camera behavior to SmartDevice dynamically.

Solution

1. Step 1: Analyze design needs

   SmartDevice needs to switch behavior dynamically between Phone and Camera at runtime.

2. Step 2: Choose delegation for flexibility

   Delegation allows SmartDevice to hold and switch between Phone or Camera instances easily without inheritance constraints.

3. Step 3: Exclude other options

   Inheritance is static and cannot switch base class at runtime; Kotlin does not support multiple inheritance; static methods do not provide instance behavior.

4. Final Answer:

   Use delegation to delegate Phone or Camera behavior to SmartDevice dynamically. -> Option D

5. Quick Check:

   Dynamic behavior switching = delegation [OK]

Hint: Use delegation for flexible runtime behavior changes [OK]

Common Mistakes:

• Trying to use inheritance for runtime behavior switch
• Assuming Kotlin supports multiple inheritance
• Using static methods instead of instance delegation