2

UIViewさんの描画が助けられていることに最初は少し驚きましたがCALayer、CALayer実際にはさんのデリゲートが助けてくれUIViewます。関係が逆転しているようです。

しかし、デリゲートには「マスターコマンダー」または「所有権」の関係がないというのは本当ですか...どの方向にも進むことができます。たとえば、クラスAはクラスBであるデリゲートを持つことができ、同時にクラスBはできるクラス A のデリゲートもあります。

さらに、複数のデリゲートが存在する可能性があります。つまり、オブジェクトは他の複数のオブジェクトからの助けを必要とします。

CTOが「誰かにインタビューする技術能力テスト」をデビッドに委任できるのは、物理的な世界に似ています。現在、デビッドは1から10のスコアを提供するための代理人です.しかし、デビッドは要件を満たすか、または「私は Javascript の候補者にしか面接できません。新しい候補者を採用できることに同意し、彼がスケーラビリティの問題に長けていることがわかった場合は、彼と一緒に仕事をすることに同意します。私たちのグループはそのような必要があるからです。」 David はこれを CTO に委任しています。

したがって、Objective-C (およびおそらく任意の言語も) では、複数のデリゲートが存在する可能性があり、それらは任意の方向に進むことができます。主なアイデアは、元のオブジェクトが処理方法を知らない「ヘルプ」のためだけです。本当？

4

5 に答える 5

2

iOS のデリゲートは実際の生活とは異なります。デリゲートは、オブジェクトの動作方法を積極的に伝えるのではなく、オブジェクトの動作方法を反応的に指示し、オブジェクトのステータスに関する更新を受け取ります。

デリゲートは、委任しているオブジェクトのステータスを監視し、(必要に応じて) オブジェクトがそのタスクを実行する方法について指示を与えるために配置されています。クラス B がクラス A を委譲しているときに、クラス A がクラス B のデリゲートになることができるなど、特定の所有権はないと言う権利があります。これは完全に問題ありません。

オブジェクトの状態に関する情報をデリゲートに提供し、デリゲートからの指示を要求する、主な 4 種類のデリゲート メソッドがあります。PeyloW は、こちらの回答でそれらを非常によく説明しています。

これはすべて、はい、あなたが正しいと言う回り道です。

于 2012-05-29T01:11:30.393 に答える
1

デリゲートは、カプセル化のオブジェクト指向の原則を支援します。UIApplicationを例にとってみましょう。あなたはそれをサブクラス化したことがありますか？まれに可能ですが、ほとんどの場合、ユーザーの不注意なサブクラス化によって影響を受ける可能性のある重要な機能を提供します。したがって、デリゲートパターンが出現します。UIApplicationは、内部で意図されたとおりに動作し、一貫して発生すると予想される特定の事前定義されたケースについて、デリゲートからキューを取得します。デリゲートのもう1つの機能は、イベント（obj-cの通知）に関連しています。オブジェクトは、外部のオブザーバーが関心を持つ可能性のある特定のイベント（たとえば、UIScrollViewの開始と終了のスクロール）をデリゲートに通知します。

ただし、通常、代理人は1人だけで、あなたが言うように複数ではありません。それが不可能だと言っているわけではありませんが、ほとんどの場合、それは珍しいことです（2人のデリゲートがセルの高さをUITableViewにフィードした場合はどうなりますか？）

したがって、あなたの例では、CTOには、Davidに通知せずに内部で使用する一連の基準がありますが、そのうちの1つについては、David（または自分以外の誰か）がタスクを実行して結果を報告する必要があります。この結果はオプション（Davidは辞退する可能性があり、CTOは彼自身の判断を使用します）または必須（Davidが「いいえ」と言った場合、彼は「仕事」を失う）である可能性があります。どちらの場合も、CTOが内部で何を考えているかを気にする必要はありません（UIApplicationがどのように機能するかを気にする必要がないのと同じです）。重要な機能は開発者からカプセル化されています。

于 2012-05-29T01:09:44.443 に答える
1

はい、デリゲートは任意の方向に進むことができます。何かのデリゲートであることは、「メイン」クラスに代わって特定のメソッドを実行することを意味するだけだからです。

これは、あなたが尋ねたことに関連している可能性があります。

Objective C の複数のデリゲート

したがって、Objective-C (およびおそらく任意の言語も) では、複数のデリゲートが存在する可能性があり、それらは任意の方向に進むことができます。主なアイデアは、元のオブジェクトが処理方法を知らない「ヘルプ」のためだけです。本当？

ほとんどの場合、次のようにクラスと目的に依存します。

@optional メソッド

これらは、上書きされた場合にメソッドの動作をカスタマイズするのに役立ちますが、実際には必要ないか、既にデフォルトの実装があります。

@必要なメソッド

これらは重要であり、あなたが言ったように、メインクラスはそれらを処理する方法を知りません。

于 2012-05-29T01:10:47.517 に答える
1

それは実際には言語ではなく、デリゲートのパターンを確立するフレームワーク (Cocoa) です。

ただし、デリゲートは通常、「プロトコル」と呼ばれる言語機能を使用して実装されます。ObjC のプロトコルは、クラスが実装を約束できるメソッド宣言のリストです。プロトコル内の各メソッドは、オプションまたは必須のいずれかです。クラスがプロトコルを採用しているが、必要なメソッドを実装していない場合、コンパイラはエラーを通知します。

実装がなく、クラス階層に結び付けられていないプロトコルは、デリゲートとそのデリゲートの間に存在する緩やかな関係に理想的です。どのクラスも、そこで宣言されたメソッドを実装することを発表する任意のプロトコルまたは多くのプロトコルを採用できます。プロトコルがデリゲーターとデリゲートの間のインターフェイスの概要を示している場合、クラスは事実上デリゲートです。

(通常、 classではなく)任意のオブジェクトをデリゲートとして使用できる理由は、デリゲート プロパティ/ivar が通常 typed であるためです。これはジェネリック オブジェクト ポインターであり、デリゲートのパターンに沿った任意の型のオブジェクトを割り当てることができます。デリゲートが知る必要があるのは、デリゲートが送信するメッセージに応答することだけです。他の行動は、そのビジネスのいずれでもありません。id

クラス A はクラス B であるデリゲートを持つことができ、同時にクラス B はクラス A であるデリゲートを持つこともできます。

もちろん、相手が必要なメソッドを実装していることをそれぞれが知っている限り、可能性はあります。頭の中で考えると、そうする理由が思い浮かびません。Cocoa のデリゲートは通常コントローラー オブジェクトであり、サブクラス化せずにフレームワーク モデル クラスの動作を変更できます。デリゲーター/モデルは、デリゲート/コントローラーに何かを行う許可を求めるか、デリゲートに何かを実行しようとしている、または実行したばかりであることを通知します。

したがって、Objective-C (およびおそらく任意の言語も) では、複数のデリゲートが存在する可能性があり、それらは任意の方向に進むことができます。主なアイデアは、元のオブジェクトが処理方法を知らない「ヘルプ」のためだけです。本当？

「どこかへ行く」という言葉の意味がよくわかりません。それも「助け」ではありません。一般的に言えば、デリゲート プロトコルが関連付けられているオブジェクトは、デリゲートが存在する必要はありません。デリゲートがなくても完全に機能します。

于 2012-05-29T01:12:13.973 に答える