重複の可能性:
コード ブロックはデリゲートを完全に置き換えますか?
フォーラムから次の宣言に遭遇しました。
「デリゲートは過去です。ブロックは未来です。」
1) ブロックは、デリゲートよりも「デリゲート」の義務を果たすため
の好ましい方法ですか?
2) デリゲートとブロックを使用する特定の利点はありますか?
重複の可能性:
コード ブロックはデリゲートを完全に置き換えますか?
フォーラムから次の宣言に遭遇しました。
「デリゲートは過去です。ブロックは未来です。」
1) ブロックは、デリゲートよりも「デリゲート」の義務を果たすため
の好ましい方法ですか?
2) デリゲートとブロックを使用する特定の利点はありますか?
デリゲートが何をするのか、ブロックが何をするのかについて、少し誤解があると思います。
Objective-C では、コールバックを処理する方法が 3 つあります。
Delegation -> あるオブジェクトを別のオブジェクトのデリゲートにする場合、「親」オブジェクトによって生成されたどの種類のイベントにデリゲート オブジェクトが応答するかを指定する必要があります。
Target-Action -> UI サブビュー (ボタン、スライダーなど) が、事前定義されたイベント ハンドラー (通常は一部の Objective-開発者が指定する C メソッド)。
通知 -> オブジェクトはNSNotificationCenter
、任意のタイプのイベントを「リッスン」するために自身を のインスタンスに登録し、それらのイベントの 1 つ以上に応答します。
ブロック自体は、委譲やその他のコールバックを処理する方法ではありません。
これらは、呼び出し元のメソッドのローカル変数とパラメーターにアクセスできる自己完結型のコードです。それらを使用して、一連のさまざまなコンテキストで動作を定義できます。ブロックの主な利点 (私が見ているように) は、コードベースを乱雑にする無関係で過度に具体的なメソッドを排除することで、コードを簡素化できることです。ブロックは、最も意味のある場所、つまりコールバック メカニズム内にコードをローカライズするのに役立ちます。
基本的に、それらを使用すると可読性が向上し、コードがより保守しやすくなります。
これらの利点により、ブロックがコールバックを処理する「好ましい」方法になるかどうかは、間違いなく個人的な意見と経験の問題です。;)