回答。

Kotlinでは、振る舞いの委譲はクラスのシグネチャに直接書かれたbyというキーワードを使用して言語的に実装されています。これにより、インターフェース（または複数のインターフェース）によるメソッド呼び出しを別の実装オブジェクトに自動的に転送し、ボイラープレートを削減し、コンポジションを容易にします。

質問の背景

インターフェースの委譲の出現は、多重継承の制約や欠点を取り除く試みです。これは「継承よりもコンポジション」というアイデアであり、クラス階層に頼ることなく振る舞いを委譲します。これは、コンポジションがより人気のある言語（例えばGoやScala）から借用されたものです。

問題

Javaや他の言語では、インターフェースを作成して各メソッドを手動で実装し、そのロジックを別のフィールドに渡さなければならないことが多く（オブジェクトアダプタパターン）、メソッドの数が増えるにつれてすぐに古くなります。

解決策

Kotlinは、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("Work started")
        // ...
    }
}
val service = Service(ConsoleLogger())
service.doWork()

Loggerのすべてのメソッドは、提供されたloggerオブジェクトを通じて実装され、Serviceクラスでは明示的にメソッドをオーバーライドしたりプロキシされたりする必要がありません。

主な特徴:

インターフェースの実装を使用から切り離し、コードの重複を減らすことができます
委譲は継承よりも柔軟で、さまざまな振る舞いに対応できます
SOLIDのベストプラクティスをサポートします

トリック質問。

Serviceクラスに同じシグネチャの自分自身のメソッドを追加するとどうなりますか？

独自の実装が「委譲」を「オーバーライド」します。つまり、クラス内で明示的に定義されたメソッドが優先されます：

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

1つのクラスが異なるオブジェクトに複数のインターフェースを委譲できますか？

はい、クラスは複数のインターフェースを異なるオブジェクトに実装および委譲できますが、各インターフェースは1つのオブジェクトに委譲されます：

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

インターフェースの委譲とは、byを介したプロパティの委譲とは何が違いますか？

インターフェースの委譲は、インターフェースの関数の全実装を別のオブジェクトに渡します。
プロパティの委譲は、特定のタイプの委譲オブジェクト（ReadOnlyProperty、ReadWriteProperty）に対するget/setの動作を委譲します。

一般的な間違いやアンチパターン

非常に大きなインターフェースの委譲（ISP違反）
明示的な実装と委譲を同時に使用すること（予期しない振る舞い）
インターフェースの委譲と親クラスとの継承を組み合わせようとして、メソッドの解決順序を無視すること

実生活の例

ネガティブケース

クラスが手動でインターフェースを実装し、各メソッドがデリゲートを呼び出し、新しいメソッドを追加する際にプロキシを更新し忘れるためにエラーが発生します。

利点:

明示的にロジックを制御

欠点:

高いエラーのリスク、ボイラープレート
インターフェースの成長に伴い、スケールしにくい

ポジティブケース

言語の委譲が使用され、非標準メソッドだけがクラス内で実装され、新しい機能が大きな変更なしで追加されます。