1

この質問は、iOS 開発に固有のものです。

を使用UITableViewし、内部でUITableViewCellsと呼ぶもう少し複雑なクラスを介して、1 つ以上のアプリケーション ビジネス オブジェクトに関する情報を表示するとしますComplexBOView。

ここで、ユーザーがに含まれるこのビューをタップしたときに特定のアクションをトリガーする必要がありますUITableCellView(イベントは を介し​​てトリガーできますUITapGestureRecognizer) 。

ほとんどの場合、「ベスト プラクティス」と見なされるのは、 のtagプロパティを使用しUIViewて実際にモデルに戻り、正しいビジネス オブジェクトを取得することです。

多くの場合、これは適していますが、ComplexBOView.

@interface ComplexBOView : UIView
{
    UILabel* lblSummary;
    // ....

    UITapGestureRecognizer* tapGesture;
    NSObject* businessObject_;
}

@property (nonatomic, readonly) UITapGestureRecognizer* tapGesture;
@property (nonatomic, assign) NSObject* businessObject;

この背後にある考え方は、ユーザーがビューをタップしたときに実際に businessObject に直接戻ることです。

ここで2つの質問

  • UIView 内に NSObject* 情報を持つのは本当に悪いことですか?
  • ビューとモデルの間の関係がここでより強くなるという意味で、この情報を保持する必要がありますか (オブジェクトに対するビューの所有権) ?

アドバイスありがとうございます。

4

3 に答える 3

1

トラウスティ・トールは正しい。その種の近道を始めるとすぐに、それは何千もの妥協の死です (別の言い方をすれば、結果として生じるコード ベースが非常に恐ろしくなり、誰もそれに触れたくない場合に備えて、技術的負債が積み重なっていきます)。他のものを壊します）。

商業的またはその他の圧力により、そうしなければならない場合があり、これらは避けられませんが、そのような妥協を行うことでその影響を最小限に抑えたいため、適切に行う機会があるときはいつでも、最初から行ってください。例外。

最後に、それが例外であり、コードのしみのようなものである場合は、おそらく静かな時間帯に戻って修正する傾向が強くなるでしょう。

于 2012-11-08T11:48:07.387 に答える
1

一般的なアドバイスは

ビューはデータを所有していません!

それは良いアドバイスです。長い目で見れば、多くの手間を省くことができます。しかし、自分自身とはどういう意味ですか? UIButtonまたはを見るとUILabel、ボタンにはtitlelabeltextプロパティがあります。したがって、彼らはいくつかのデータを保持しています。彼らはそうしなければなりません-代わりに、描画されるたびにテキストを要求されるデリゲートが必要です。

それで、あなたの場合、それはどういう意味ですか？まあそれは依存します。あなたの特定のビジネスオブジェクトを表示ComplexBOViewするために特別に設計された単なる一般的なビューである場合、そのオブジェクトをそのプロパティに保持することは最悪ではありません(私の意見です)。

もちろん、そのビューを別のモデルで簡単に再利用する可能性は失われますが、非常に具体的であるため、とにかくそれはオプションではありません。もちろん、すべてのコードを からComplexBOViewコントローラーに移動することもできます。しかし、あなたが言ったように、各モデル オブジェクトと適切なビューの間の接続も維持する必要があります。（ちなみに、私はそれを行うために を使用しません。tag代わりに NSDictionary を使用する方が良いです）

一方、Trausi と Michael には有効なポイントがあります。今回その「ルール」を破ると、それ以外の機会に解き放たれる可能性があり、気付かないうちに、モデルの一部への参照を保持するカスタム ビューが多数作成されることになります。長期的には、モデルに変更を加える可能性があります (おそらく、最初は予想もしていなかった方法で - 信じてください、それは頻繁に起こるでしょう)。そして、すべてのサブクラスに行き、それらを調整する必要があります。 . もちろん、そのモデル固有のコードがコントローラーにある場合は、それもすべて変更する必要がありますが、少なくともすべてが 1 か所にあります。

要約すると、これらのベスト プラクティス、アドバイス、および設計パターンには正当な理由があります。それらは数え切れないほどのケースで有用であることが証明されました。したがって、一般的には、それらに従うだけで良い結果が得られます。ただし、それらに違反する価値がある場合もありますが、いくつかの非常に正当な理由が必要であり、その結果を認識しておく必要があります。

最終的には、それはあなたのコードであり、あなたのデザインであり、あなたの決定です。推測が間違っているかもしれませんが、いくつかの教訓は難しい方法で学ばなければなりません。次回は、何をすべきか、さらに重要な理由がわかります。自分の経験を作ることは常に価値があります。

于 2012-11-08T12:32:16.040 に答える
1

デリゲートの設計に固執する必要があります。コードのサポートがいつ必要になるかはわかりませんが、人々はデリゲートの使用を期待しています。私の意見では、これはあなたのコードをスパゲッティ化します。

特にテーブルビューでは、ビューがリサイクルされることに注意してください。ビューが見えなくなると、それは再利用されるため、控えめに言っても維持するのが複雑になります。

于 2012-11-08T11:38:19.680 に答える