Apple のガイドラインに従って、iPhone アプリケーションの画面ごとに UIViewController のサブクラスを 1 つ作成します。しかし、これらのクラスはコードの行数とメンバー変数の数の両方の点で非常に大きくなることが一貫してわかっています。
定義上、それらは非常に多くの異なる問題 (たとえば、ビューのライフ サイクル、ビューとモデルの間の仲介、場合によってはタッチ処理、制御ロジック、アラートの管理、その他の UI 状態など) を担当することになります。
これは、単一責任の原則に違反するだけでなく、単体テストがほぼ不可能な大量のコードが生成されます。
どのような責任/懸念事項を新しいクラスに分割する傾向がありますか? UIViewController サブクラスの場合、どのような種類の責任が明確な分離の良い候補になると思いますか?
これは興味深い質問であり、責任を適切に分離する方法についても苦労しています。それはすべてコンテキストに依存しますが、UIVieController のサブクラスをテストするのは面倒なので、できる限りモデル クラスに移行しようとします。Skinny Controller、Fat Modelの精神で。
テーブルに関しては、すべてのテーブル ビューを処理するための基本モデル クラスを作成しました。これは基本的に、新しいナビゲーション ベースのコア データ プロジェクトを作成するときに得られるものをカプセル化したものです。コントローラーでは、呼び出しをテーブル モデルに転送するだけです。
コントローラーのメソッドをできるだけ小さくしようとしています。コンテキストに応じて、いくつかのモデル クラスがあり、それぞれが特定の部分を担当します。
また、特定のデータ モデルの詳細なコントローラーを取得するためにコントローラー ファクトリを使用する可能性についても調べました。
UIViewController *detailController = [self.controllerFactory controllerForItem:item];
[self presentModalViewController:detailController animated:YES];
このようにして、親コントローラーを関与させることなく、特定のデータ項目に適切なコントローラーを取得することを単体テストできます。
私の場合、カテゴリを作成し、親を抽象化し、Javaの世界で学んださまざまなパターンを使用して、複雑さとコードの重複を減らしています。しかし、結局のところ、すべての画面には何らかの形でユニークなものが少なくとも1つあるため、画面ごとに1つのViewControllerがあります。私がコントローラーの周りに配置したインフラストラクチャのおかげで、コントローラーにあまりコードが残っていない可能性があります。