Odpowiedź.

W Kotlinie delegowanie zachowania jest zrealizowane za pomocą językowego mechanizmu słowa kluczowego by, bezpośrednio w sygnaturze klasy. Pozwala to na automatyczne przekazywanie wywołań metod interfejsu (lub kilku interfejsów) do innego obiektu z implementacją, zmniejszając boilerplate i ułatwiając kompozycję.

Historia pytania

Pojawienie się delegowania interfejsu to próba usunięcia ograniczeń i wad wielokrotnego dziedziczenia. To idea "kompozycja zamiast dziedziczenia" – delegujemy zachowanie bez korzystania z hierarchii klas. Zapożyczone z języków, gdzie kompozycja jest bardziej popularna (np. Go, Scala).

Problem

W Javie i innych językach często trzeba tworzyć interfejs i ręcznie implementować każdą metodę, przekazując logikę do innego pola (wzorzec Object Adapter), co szybko staje się nieaktualne w miarę wzrostu liczby metod.

Rozwiązanie

Kotlin umożliwia deklaratywne delegowanie interfejsu za pomocą by:

interface Logger {
    fun log(msg: String)
}
class ConsoleLogger: Logger {
    override fun log(msg: String) = println(msg)
}
class Service(logger: Logger): Logger by logger {
    fun doWork() {
        log("Praca rozpoczęta")
        // ...
    }
}
val service = Service(ConsoleLogger())
service.doWork()

Wszystkie metody Logger są zaimplementowane przez dostarczony obiekt logger, przy czym w klasie Service nie ma potrzeby jawnego nadpisywania ani proxy'owania metod.

Główne cechy:

Umożliwia oddzielenie implementacji interfejsu od użycia, zmniejsza powtarzalność kodu
Delegowanie jest bardziej elastyczne niż dziedziczenie i działa z wieloma zachowaniami
Wspiera najlepsze praktyki SOLID

Pytania z podstępem.

Co się stanie, jeśli w klasie Service dodamy swoją własną metodę interfejsu o tej samej sygnaturze?

Własna implementacja "przykrywa" delegowaną — czyli przeważa metoda zdefiniowana jawnie w klasie:

class Service(logger: Logger): Logger by logger {
    override fun log(msg: String) = println("PREFIX: $msg")
}

Czy jedna klasa może delegować kilka interfejsów do różnych obiektów?

Tak, klasa może zaimplementować i delegować kilka interfejsów do różnych obiektów, ale każdy interfejs jest delegowany do jednego obiektu:

class Service(
    logger: Logger,
    tracker: Tracker
): Logger by logger, Tracker by tracker

Czym delegowanie interfejsu różni się od delegowania właściwości przez by?

Delegowanie interfejsu przekazuje całą implementację funkcji interfejsu do innego obiektu.
Delegowanie właściwości (delegacja właściwości) deleguje operacje get/set do obiektu delegowanego specyficznego typu (ReadOnlyProperty, ReadWriteProperty).

Typowe błędy i antywzorce

Delegowanie zbyt dużych interfejsów (naruszenie ISP)
Jednoczesne stosowanie jawnej implementacji i delegowania (nieprzewidywalne zachowanie)
Próba połączenia delegowania interfejsu i dziedziczenia z klasą rodzicielską, ignorując kolejność rozwiązywania metod

Przykład z życia

Negatywny przypadek

Klasa ręcznie implementuje interfejs, każda metoda wywołuje delegata, przy dodawaniu nowych metod zapomniano zaktualizować proxy, co prowadzi do błędów.

Plusy:

Jawnie kontrolowana logika

Minusy:

Wysokie ryzyko błędów, boilerplate
Źle skalowalne w miarę wzrostu interfejsu

Pozytywny przypadek

Używane jest delegowanie językowe, tylko niestandardowe metody są implementowane wewnątrz klasy, nowa funkcjonalność dodawana jest bez większych zmian.