View ControllerクラスをVCとカスタムクラスに分割するルールは何ですか？

Question

ビュー、IBActions、IBOutlets、および他のビュースクリーン関連のものだけを管理するために、AFAIKビューコントローラクラスを使用する必要があります。つまり、View Controllerクラスは、ルートビューと内部ビューの管理に関してのみ、できるだけ軽量でなければなりません。しかし、時にはView Controllerクラス内にコードを残し、他のカスタムクラスに移動したくないということもあります。

現在、モデル（データベーステーブルまたはカスタムオブジェクト）、パーサーラッパー、重い計算、多かれ少なかれ大規模な別のクラスと見なされる可能性のある他のロジック用のカスタムクラスを作成します。しかし、非常に頻繁に、私は怠惰な（そして誰でないの？）ため、ビューコントローラクラスの中で、比較的小さな計算、簡単なチェック、簡単なダウンロード、その他の小さなコードを残しています。理論的にはいくつかのいくつかのコードステートメントがいくつかのView Controllerクラスに属していないからです。私は、これらの小さなクラスは、アプリケーションの他のバージョンでは、より大きなクラスと実際のクラスに進化するかもしれないと理解していますが、そうではないかもしれません。

IMHO、あなたが100％の純度と清潔さに心配するなら、あなたはもっと多くの時間を費やすでしょう（少なくとも最初のバージョンのアプリケーションでは）、製品が進化するかどうか、放棄されます。開発者が直面しているトレードオフは、常にあります。

あなたのクラスを設計するために社内のルールをどのように使用しているのか興味深いです。

Answer 1

実際には、あなたがパターンに固執しているかどうかにかかわらず、何かをしなければならないときは、2つの質問が本当にあります。 そしてどうすればいいですか 特に、実用性とプラグマティズムがあなたの顔に乗り始めたら、はるかに明確ではありません。

単純なものの静的クラスに行く傾向があります。さまざまな形式の日付を解析して整形するためのDateUtilityクラスです。

大きなもの、つまりダウンローダー用の集約。

再利用が必要な場合は、デカップルが基本ルールなので、大きなものがあったとしても必ずしも別のクラスであるとは限りません。

Answer 2

個人的に私は厳密なクラス分離をしたいと思っています。（ すべてのオブジェクトがその目的を持っています。もし私が本当に一般的な操作を見つけたら、 "ヘルパー"クラス文脈に固有のものではないことがあります。

本当に難しいのは、あなたの決定に厳しく、怠惰ではないということです。あなたの質問では、あなたのコードに厳密にいかに重要かを理解しているからです。