Ответ

История вопроса:

Паттерн "Делегирование" известен многим языкам ООП, это принцип передачи работы одному объекту другому. В Java делегирование реализуется вручную — через внутреннее поле и проксирование методов. В Kotlin делегирование вынесено на уровень синтаксиса с помощью ключевого слова by.

Проблема:

Реализация паттерна делегирования в Java ведет к "божественным" прокси-классам, перегруженным шаблонным кодом и большими трудозатратами на поддержку интерфейса. Сложно поддерживать обновление контрактов интерфейса и изменять делегатов.

Решение:

Kotlin разрешает создавать классы, реализующие интерфейс не напрямую, а делегируя все его методы другому объекту через запись class Foo(...) : MyInterface by delegateObj. Это позволяет писать лаконичный и понятный код, избавляясь от рутины без потери гибкости.

Пример кода:

interface Base {
    fun print()
}

class BaseImpl(val x: Int) : Base {
    override fun print() = println(x)
}

class Derived(b: Base) : Base by b

fun main() {
    Derived(BaseImpl(42)).print() // 42
}

Ключевые особенности:

Декларативное делегирование методов интерфейса
Сокращение количества шаблонного кода
Гибкое изменение логики делегирования и подмена реализации

Вопросы с подвохом.

Может ли класс-декларант изменить поведение конкретного метода, несмотря на делегирование?

Да — если реализовать метод интерфейса явно в классе-делегате (Derived), он "переопределит" делегируемое поведение для конкретного метода.

Пример:

class Derived(b: Base) : Base by b {
    override fun print() = println("Overrided!")
}

Можно ли делегировать сразу несколько интерфейсов разным объектам?

Нет, в Kotlin напрямую нельзя делегировать несколько разных интерфейсов разным объектам в одной декларации. Придется писать класс с ручным делегированием или комбинировать наследование и делегирование, если архитектура это допускает.

Работает ли делегирование с абстрактными классами или только с интерфейсами?

Делегировать можно только интерфейсы, не абстрактные классы — поскольку у абстрактных классов могут быть состояния и protected методы, несовместимые с декларацией делегирования через by.

Типовые ошибки и анти-паттерны

Желание использовать делегирование для абстрактных классов (компилятор не позволит)
Попытки сделать множественное делегирование через один класс
Пренебрежение расширяемостью при сложном продакшн-коде

Пример из жизни

Негативный кейс

Разработчик вручную реализует паттерн делегирования для десятка методов большого интерфейса. При каждом расширении интерфейса забывает добавить новые методы-прокси. Код разрастается, баги множатся.

Плюсы:

Четкий контроль за каждой логикой делегирования

Минусы:

Перегруженность класса
Поддержка дорого обходится

Позитивный кейс

Использован синтаксис by для автоматического делегирования интерфейса. Легко менять реализацию и подменять делегата на лету, особо не рискуя ошибиться при поддержке контракта.