主に MVC ベースのアプリケーションを行う Web 開発のバックグラウンドを持つ私は、コードのコンポーネントを 3 つのファイル グループ (コントローラー、モデル、ビュー) に分けることに慣れています。
しかし、iOS アプリケーションで MVC パターンを使用していても、同じ手法に従うことに意味があるのでしょうか?
UIViewControllerは、残りのサブビュー ( 、 、...) を追加してすぐにアクセスできるデフォルト ビューを提供しUILabelますUIButton。言語は同じです。HTML/CSS などを処理する必要はありません。
UIViewしかし、 でのみ使用される場合でも、 がサブクラス化され、別のファイルで管理されている iOS アプリケーションに出くわしましたUIViewController。したがって、内部サブビューを処理するには、カスタム アクセサーをコーディングする必要があります。
もちろん、同じものUIViewをいくつかの場所で再利用したり、カスタム描画を行ったりしない限り、それを行う必要はないと思います。
私たちの多くは、確かに MVC の行を少しぼやけさせ、少量のビュー関連のコードをコントローラーに滑り込ませます。個人的にはそれでいいと思います。それは、私たちが依然として MVC パターンにほぼ従っているという事実 (そして、Cocoa クラスがビューのために大変な作業を行っているという事実) を損なうものではありません。しかし、私にとっては、ビュー関連のコードが些細なことを超えて拡張される場合、ビューをサブクラス化することを選択していることに気づきます。
宗教的に をサブクラス化する人もいるでしょうがUIView、少し実用主義が必要だと思います。些細な量のビュー関連のコードを追加する場合、それを新しいUIViewサブクラスに抽象化することで、コードの読みやすさが向上しますか? 常にではない。しかし、この状況 (サブクラス化する必要がないのに誰かがサブクラス化する) は、反対の問題 (サブクラス化すべきなのにサブクラス化に失敗する) よりもはるかに一般的ではないと思います。
それで、あなたは尋ねました：
もちろん、同じUIViewを複数の場所で再利用したり、カスタム描画を行ったりしない限り、[UIViewのサブクラス化]を行う必要はないと思います。
drawRect再利用とカスタム描画 (例: ) が 2 つの優れた例であることに同意します。ただし、ビューが十分に複雑であるため (確かに主観的な呼び出しです)、サブクラス化によってコードの読みやすさが向上する場合は、サブクラス化するという原則も追加します。2 つの例:
アプリにカレンダー ビューがありましたが、View Controller が扱いにくくなり、月のさまざまな日のすべてのセルを管理するなどしてUIViewいました。カレンダービューで構成されています。メインの「月」ビューだけでなく、「月」ビュー内の「日」ビューもサブクラス化しました。再利用自体はありません。カスタム描画はありません。しかし、それは明らかに正しいことでした。コードははるかに読みやすくなっています。
UITableViewCellテーブルビューのサブクラス化を増やしています。私の最初のプロジェクトではcellForRowAtIndexPath、そのセルの複雑な構成とレイアウトをすべてテーブル ビュー コントローラーに任せていました。UITableViewCell標準のセル型のいずれかを使用していない状況では定期的に をサブクラス化するようになったので、私のコードははるかに簡単に理解できるようになりました。
要するに、UIViewView Controller ごとに a をサブクラス化することを強制されるべきではないことに同意しますが、個人的には、ビューが特定のレベルの複雑さに達したときにそうしようとします。私は、コードの読みやすさが私の慣行を支配するようにしています。以前よりもビューをサブクラス化していることがわかりましたが、常にそうしているわけではありません。
結論として、常にビューをサブクラス化する必要はありませんが、多くの開発者はビュー (またはモデル) をサブクラス化する必要があるときにサブクラス化を怠っているという罪を犯していると個人的には思います。MVC に準拠したいという熱狂的な願望からそうすべきではありませんが、ビューまたはモデルを適切にサブクラス化した場合、コードが読みやすく維持しやすくなるかどうかを自問する必要があります。
通常、私はUIViewController<=>SingletonManager<=>実際のデータソースを持っています。私は物事をうまく分離しておくことを好みます。自分でカスタム描画を行うカスタムがUIViewある場合は、それが理にかなっているため、別のファイルを使用します。私が1つの場所でしか使用していない場合でも（明日何が必要になるかわからないため、別の場所で必要になる可能性があります）。また、iOSではMVCが十分に分離されていることも忘れないでください。
iPhoneとiOSの同じアプリの違いに対処するので、これは良いパターンになる可能性があります。iPadのDetailViewControllerは、iPhoneのUINavigationControllerである可能性があります。
もう1つの一般的なパターンは、ビューがデータソースに依存せず、複数のコントローラーで再利用できる一方で、コントローラーがデータソースに結合されることです。
ビューはビューコントローラーにありません。これらは個別のクラスにあるか、ビューコントローラーによって読み込まれるnibファイルにあります。ビューコントローラーはそのビュー用に作成されているため、すべてのアクションとアウトレットがそのビューに接続されます。
ペン先またはサブクラスの使用について質問している場合、コンポジションと継承のどちらかを選択するのと同じです。
特別なビューが必要な場合は、UIViewをサブクラス化しますが、コントロールをサブビューとして持つビューが必要な場合は、compositionを使用すると、InterfaceBuilderを使用してビューを作成する方が簡単です。
サブビュー専用のUIViewのサブクラスがあると思う唯一の理由は、カプセル化を改善するためですが、コントローラーはビュー用に特別に作成されているため、このカプセル化は必要ありません。