2

かなり長い間、Objective Cの例を見たり、スタンフォード大学の講義を見たり、iOSアプリの作成のコツをつかむためにコードをいじったりしてきました。

しかし、私が良い答えを見つけることができないいくつかのことがあります：

  1. レイヤーを適切に分離するにはどうすればよいですか？MVC構造を理解し、ビジネスロジックを実装するためのモデルのカテゴリを作成する例をいくつか見ました。それは、モデルを強化することによる適切な方法ですか、それとも専用のクラスを作成する必要がありますか（たとえば、ユーザーの認証、jsonからのモデルの抽出、グループ注文）？

  2. ビューはどの程度スマートである必要がありますか？（連絡先プロパティを割り当てることによって）連絡先を表示するビューを作成できますか、それともすべての連絡先フィールドに個別のプロパティを作成する必要がありますか、またはビューはデリゲート呼び出しを介してその情報を要求する必要がありますか？

  3. アプリケーションでストーリーボードを使用しています。画面にナビゲーションバーが必要です。たとえば、注文を表示するビューを表示します。他の画面では、オーダービューを再利用したいと思います。

    • オーダービューのViewControllerとViewを他のViewControllerで再利用するにはどうすればよいですか？
    • 同じルックアンドフィールの画面が4つある場合、ストーリーボードにそれらをコピーするだけで済みますか？これはメインの苦痛のようですが、背景を変更したい場合はどうすればよいですか？または、すべてのビューにボタンを追加しますか？セットアップウィザードを作成するとき、すべての画面のルックアンドフィールを個別に定義したくありません。

C＃のバックグラウンドから来て、私はおそらくObjective-Cの考え方に入る必要があります:)
これに関するどんな助けも素晴らしいでしょう。

4

2 に答える 2

5

1）ObjC-カテゴリは、直面している主な問題の理解を簡単に歪めます。ObjC-カテゴリは完全に不要です。サブクラス化、オブジェクトコンポジション、実際のモデルの追加メソッド、またはコントローラーやビューのカスタマイズによって、これらの拡張機能にいつでもアプローチできます。したがって、ビューに表示するためにデータ（モデルに存在するデータなど）をフォーマットする必要がある場合、そのタスクは多くの場合、コントローラーに到達します。提供する例に関する限り、単純なケースでモデルを選択できます。同様に、十分に複雑な場合、または冗長な実装を妨げる場合は、どの例も専用クラスに値する可能性があります。これらは、単にモデルを生成するアクセサリクラスの場合もあれば、抽象クラスの複数の具象の複合である場合もあることに注意してください。M-or-V-or-Cの定義では、すべてが真っ直ぐに着地する必要はありません。ObjCでは多くのデザインパターンを自由に使用できます。MVCは、Cocoaが通常使用するパターンと考えてください。これらを知る必要があり、これらのタイプをサブクラス化して拡張する方法を知る必要がありますが、実装がCocoaのライブラリから離れるにつれて（複雑さが増すなど）、これらのパターンの優位性は失われます。 。

2）彼らは賢くすることができます。ただし、MVCでは、その実装をビュー/プレゼンテーションの側面に集中させる必要があります。情報のコレクションを表すビューは、実際には、通常はコントローラー用に予約されているいくつかのタスクを実行できますが、通常、実装はそのMONContactViewための専用であると認めます。そのルートを使用する場合は、通常、再利用を容易にするため、または単純なインターフェイスを実現するために実行します。に関する情報の表示Contactは非常に複雑になる可能性があります-単純なシナリオでは、これらのタスクは多くの場合、コントローラーによって処理されます。具体的には、aMONAwesomeContactViewは（SLOCなどで）より複雑ではない可能性がありますMONAwesomeContactViewController（実行する非常に特別な描画またはレイアウトがない場合）。コントローラの連絡先を設定し、コントローラに連絡先データをビューのフィールドにプッシュさせるのがより一般的です。繰り返しになりますが、非常に特殊なサブクラスの場合、ビューは独自のコントローラーを保持できる場合があります。

3a）クラスの複数のインスタンスを作成しても問題はありません。

3b）コピーする必要はありません。重複の匂いがするときは、実装を実際のコードにプッシュします。プログラムは、必要に応じてルックアンドフィールを適用したり、サブビューを追加または操作したりできます。もちろん、XcodeのNIBエディターには表示されません。もちろん別のアプローチもありますが、このレプリケーションにより、実装をコンパイル済みコードに移行することがよくあります。両方のバランスをとることはそれほど難しくありません（個人的には、NIBを使用するのではなく、プログラムでほとんどのビューを実行します）。

于 2012-08-12T05:44:22.503 に答える
1

  1. これはかなり抽象的な質問であり、「レイヤー」が何を意味するのかは明確ではありません。はい、必要に応じて独自のクラスを作成する必要がありますが、カテゴリには、既存のクラスに機能を追加するオプションもあります。質問をより具体的にすることができれば、より良い答えを提供するのが簡単になります。

  2. それは判断の呼びかけです。Contactタイプのインスタンスを表示する方法を知っているビュークラスを作成したい場合は、私の本では問題ありません。ただし、そのビューが連絡先がアプリのどこに保存されているかを知っている場合、それはあまり良くありません。

  3. ストーリーボードにあるものはオブジェクトであり、クラスではないことを忘れないでください。あるシーンのビューを別のシーンで再利用しようとしないでください。つまり、シーン間でビューを共有することになりますが、これは実際には機能しません。複数の場所で同じ順序ビューを使用する場合は、クラスを作成するのに適しています。一方、ストーリーボードを設定して、複数の異なるシーンがすべて同じシーンに移行するようにすることもできます。たとえば、アプリのさまざまな部分で注文を表示するシーンをモーダルに表示したい場合は、それを行うことができます。

于 2012-08-12T05:39:24.907 に答える