今、私は自分のアプリの構造について考えています。UIView をサブクラス化して、アプリのメイン フローのコントローラーとして機能する「ルート ビュー」を作成することを考えました。したがって、UIView のサブクラスには、表示されているコンテンツの変更を実行する、たとえばサブビューによって呼び出されるメソッドがあります。これはプログラミングの構造 (/スタイル) が悪いと思いますか? もしそうなら、なぜそれは悪いのか、エレガントではないのでしょうか? 助けてくれてありがとう:)
sh4kesbeer
ビューはユーザーに何かを表示する必要があります。コントローラーはアプリケーション ロジックを実装する必要があります。これは、ユーザーに表示する必要があるビューを選択するコントローラーであることを意味します。
もっと何かを勉強したい場合は、アップルのドキュメントまたはウィキペディアの内容をご覧ください。
標準のコールバック、navController の統合、tabBarController のサポートなど、UIViewController 用に設計された優れたパターンをすべて使用していないことを除けば、UIView をスタンドアロンで使用するか、UIViewController にラップするかの論理的な違いはありません。また、コード リストが大きくなり、読みにくく/理解しにくくなります。 .
ただし、ここに要点があります。OOP の観点からすると、メッセージングにも影響するカプセル化レベルを下げています。そして今、キラーに会いましょう: あなたはいくつかの視点からほとんど見えないほど小さくしていますC.MVC
私の経験から、ビューベースのプロジェクトは問題なく開始されますが、あらゆる種類の困難があなたのドアにやって来て、ビューコントローラーをゼロから発明するリファクタリングについて考える必要があります。