8

これはかなり一般的な質問ですが、今日デリゲートについて疑問に思っていました。現時点では、ピッカーやテーブルビューのものからの選択を渡すなどの明らかなケースを除いて、それらを使用するか使用しないかという特定の時間は実際にはありません。たとえば、オブジェクトへの参照を渡し、それを使用してメソッドを呼び出すことができる状況がある場合、デリゲートを実装する理由はありますか? 要約すると、使用を意図したデリゲート パターンとは何ですか。

迅速かつ包括的な回答をありがとう!それらはすべて非常に役に立ちました。

4

3 に答える 3

5

デリゲート パターンの利点は、委任オブジェクトとそのデリゲートの間の疎結合です。疎結合により、他のコンテキストでのクラスの再利用性が向上します。

委譲オブジェクトは、通信相手のオブジェクトについて何も知る必要はありません (デリゲート プロトコルを実装するという要件は別として)。後で別のコンテキストでコンポーネントを再利用したり、別のクラスの別のオブジェクトと通信したりする場合、このオブジェクトが行う必要があるのはデリゲート プロトコルを実装することだけです。委任オブジェクトを変更する必要はまったくありません。

もちろん、これにはマイナス面もあります。それは、もう少しコードが必要であり、記述したコードがそれほど明示的ではないため、理解するのが少し難しくなる可能性があることです。この (通常は小さい) トレードオフが価値があるかどうかは、ユース ケースによって異なります。いずれにせよ 2 つのオブジェクトが密結合されており、将来再利用される可能性が低い場合、デリゲート パターンを使用するのはやり過ぎかもしれません。

于 2012-07-02T13:33:05.720 に答える
3

この議論を見る

デリゲートを使用すると、イベントが発生したときに、あるオブジェクトから別のオブジェクトにメッセージを送信できます。

長所

  • 非常に厳密な構文。聴取されるすべてのイベントは、デリゲート プロトコルで明確に定義されています。

  • メソッドがデリゲートによって実装されている必要があるように実装されていない場合のコンパイル時の警告/エラー。

  • コントローラーのみのスコープ内で定義されたプロトコル。

  • 非常に追跡可能で、アプリケーション内の制御フローを簡単に識別できます。

  • 複数のプロトコルを 1 つのコントローラーに定義し、それぞれに異なるデリゲートを設定する機能。

  • 通信プロセスを維持/監視するために第三者オブジェクトは必要ありません。

  • 呼び出されたプロトコル メソッドから戻り値を受け取る機能。これは、デリゲートがコントローラーに情報を返すのに役立つことを意味します。

短所

  • 1. プロトコル定義、2. コントローラー内のデリゲート プロパティ、および 3. デリゲート自体内のデリゲート メソッド定義の実装を定義するために、多くのコード行が必要です。

  • オブジェクトの割り当て解除時にデリゲートを nil に正しく設定するように注意する必要があります。そうしないと、割り当て解除されたオブジェクトでメソッドを呼び出すことによってメモリ クラッシュが発生する可能性があります。

  • 可能ではありますが、困難な場合があり、パターンは、コントローラーに同じプロトコルの複数のデリゲートを持つ (同じイベントについて複数のオブジェクトに伝える) ことに実際には適していません。

于 2012-07-02T13:31:05.633 に答える
2

委任の「使用例」は、継承の場合とほとんど同じです。つまり、クラスの動作をポリモーフィックな方法で拡張します。

これは、ウィキペディアが委任を定義する方法です。

ソフトウェア エンジニアリングでは、委任パターンはオブジェクト指向プログラミングの設計パターンであり、オブジェクトは、指定されたタスクの 1 つを実行する代わりに、そのタスクを関連付けられたヘルパー オブジェクトに委任します。デリゲートと呼ばれるヘルパー オブジェクトにデリゲータのタスクを実行する責任が与えられる、責任の反転があります。委譲パターンは、コンポジション (アグリゲーションとも呼ばれます)、ミックスイン、アスペクトなどの他のソフトウェア パターンの基礎となる基本的な抽象化パターンの 1 つです。

委任と継承の間には明らかに多くの違いがありますが、最大のものは、IMO によると、継承は 2 つのクラス間の固定された (別名、コンパイル時の) 関係であるのに対し、委任は実行時に定義できます (言語ではこれをサポートします)。一方、継承はポリモーフィズムをより適切にサポートします。

委任は (継承と同様に) 巨大なトピックであり、それについては多くの記事を読むことができます。最終的に、委譲を使用するか継承を使用するかを決定することは、「is-a」または「has-a」のどちらの関係が必要かを決定することになるため、それを選択するためのガイドラインを列挙するのはそれほど簡単ではありません.

私にとって、基本的に、デリゲートを作成するという決定は、次の観察から得られます。

  1. 私のコードは一連の同種の動作を示します (ここで同種とは、共通の「性質」を持つと認識できることを意味します)。

  2. これらの動作は、特定のケースに合わせて「カスタマイズ」される場合があります (代替動作に置き換えられた場合など)。

これは私の個人的な見解であり、「委譲」パターンを特定する方法の説明です。これはおそらく、私のプログラミング分野がリファクタリングの原則に強く影響を受けているという事実と関係があります。

本当に、IMO、委任はクラスの「カスタマイズ」ポイントを定義する方法です。例として、ある種の抽象的なワークフローがある場合、各ステップで特定の条件に応じて何らかのアクションを実行します。さらに、これらの具体的なアクションは別の種類のものに置き換えることができます。その場合、委任を通じて再利用できる可能性があります。

お役に立てれば。

于 2012-07-02T13:46:27.327 に答える