委任の「使用例」は、継承の場合とほとんど同じです。つまり、クラスの動作をポリモーフィックな方法で拡張します。
これは、ウィキペディアが委任を定義する方法です。
ソフトウェア エンジニアリングでは、委任パターンはオブジェクト指向プログラミングの設計パターンであり、オブジェクトは、指定されたタスクの 1 つを実行する代わりに、そのタスクを関連付けられたヘルパー オブジェクトに委任します。デリゲートと呼ばれるヘルパー オブジェクトにデリゲータのタスクを実行する責任が与えられる、責任の反転があります。委譲パターンは、コンポジション (アグリゲーションとも呼ばれます)、ミックスイン、アスペクトなどの他のソフトウェア パターンの基礎となる基本的な抽象化パターンの 1 つです。
委任と継承の間には明らかに多くの違いがありますが、最大のものは、IMO によると、継承は 2 つのクラス間の固定された (別名、コンパイル時の) 関係であるのに対し、委任は実行時に定義できます (言語ではこれをサポートします)。一方、継承はポリモーフィズムをより適切にサポートします。
委任は (継承と同様に) 巨大なトピックであり、それについては多くの記事を読むことができます。最終的に、委譲を使用するか継承を使用するかを決定することは、「is-a」または「has-a」のどちらの関係が必要かを決定することになるため、それを選択するためのガイドラインを列挙するのはそれほど簡単ではありません.
私にとって、基本的に、デリゲートを作成するという決定は、次の観察から得られます。
私のコードは一連の同種の動作を示します (ここで同種とは、共通の「性質」を持つと認識できることを意味します)。
これらの動作は、特定のケースに合わせて「カスタマイズ」される場合があります (代替動作に置き換えられた場合など)。
これは私の個人的な見解であり、「委譲」パターンを特定する方法の説明です。これはおそらく、私のプログラミング分野がリファクタリングの原則に強く影響を受けているという事実と関係があります。
本当に、IMO、委任はクラスの「カスタマイズ」ポイントを定義する方法です。例として、ある種の抽象的なワークフローがある場合、各ステップで特定の条件に応じて何らかのアクションを実行します。さらに、これらの具体的なアクションは別の種類のものに置き換えることができます。その場合、委任を通じて再利用できる可能性があります。
お役に立てれば。