0

演習として、iPad 用の簡単な描画アプリに取り組んでいます。私はUISplitView、図面ビューを詳細図として使用しています。マスター ビュー コントローラーで、これまでに描画した図形の一覧を (テーブル ビューで) 表示します。

ユーザーは、マスター ビュー コントローラーから任意の形状を編集または削除できます。また、詳細ビュー コントローラーで形状をタッチして選択および編集することもできます。

他のビュー コントローラーが行った変更を各ビュー コントローラーに通知するために、デリゲートを使用することを考えましたが、これが正しいパターンであるかどうかはわかりません。

まず、私が理解しているように、デリゲートは、特定のオブジェクトが処理方法がわからないイベントに遭遇したときに使用されることになっています。その場合、すべての情報をデリゲートに渡し、デリゲートにイベントを処理させます。ここでは、両方のビュー コントローラーが情報を処理する必要があるため、これは当てはまりません。ここでデリゲートを使用すると、コードの繰り返しが発生する可能性があります。

デリゲートを使用しないと考えているもう 1 つの理由は、将来、他のビュー コントローラーが図面の変更情報を取得できるようにする可能性があるためです。複数のデリゲートを使用できます (一般的に良い方法ですか?) が、これも良い解決策かどうかはわかりません。

他に検討すべき解決策はありますか?

4

1 に答える 1

0

逆に、デリゲートはここで使用するのに適したパターンであると思います。イベントを処理できない場合にのみデリゲートする必要はありません (デリゲートする状況の 1 つかもしれません)。

代わりに、そのオブジェクトが何であるかわからない場合に、デリゲートを別のオブジェクトとの間で情報を取得する方法と考えてください。たとえば、Apple は UITableViews を操作するときにデリゲート パターンを使用します。そのデリゲート プロトコルでは、テーブル ビューはそれぞれの状況で何をすべきかを完全に認識していますが、特定のアクションが発生しようとしているときにコードに通知します。それはあなたの状況と非常によく似ていると思います。（テーブルビューがいくつかの情報を必要とするUITableViewの「データソース」にも、質問の仮定と類似していることに注意してください。）

デリゲートに対して本当に行き詰まっている場合、使用を検討できる別のテクノロジは、通知を使用することです。各コントローラーに特定の通知をサブスクライブさせ、観察可能な変更が発生したときに形状 (または詳細ビュー コントローラー) に NSNotification のインスタンスを投稿させることができます。そうすれば、別のコントローラーで発生するイベントを引き続き処理できますが、デリゲート リストを維持する必要はありません。

コードの重複については、重複する状況に遭遇し始めたときにリファクタリングを検討してください。おそらく、共通コード用に単一のデリゲートまたは通知サブスクライバー オブジェクトを設計し、その後、他のコントローラーのそれぞれでクラス固有のことのみを行う必要がありますか?

于 2012-08-01T16:34:55.507 に答える