すべての新しいUi（フラグメント/アクティビティ）に対して新しいviewModelクラスを作成するのは良い方法ですか？

Question

私はGoogleのクリーンなアーキテクチャに従っているプロジェクトに取り組んでいます...コードをテスト可能にするために、私は新しいアプローチを作成しているアプローチに従っています

ViewModelクラス
ViewModelファクトリ
短剣コンポーネント
ダガースコープ

すべての画面で、他のすべてのクラスから独立しています。しかし、それが原因で、あまりにも多くのクラスが作成され、アーキテクチャが乱雑になってしまいます。これは、彼が私のプロジェクトを見た場合、他の誰かからも好まれません。 SO、問題は、すべてを個別に作成することは良いアプローチですか？そうでない場合、なぜですか？

Flater · Accepted Answer

短い答え

この問題に対する主なコンセンサスは、可能な限り分離を支持することになると思います。

私はこのコンセンサスの根本的な意図に完全に同意しますが、それが（ほとんど盲目的に）包括的ルールとして適用される程度については多少は同意しません。この回答の残りの部分は、私が同意しない部分に焦点を当てています。なぜなら、私の部分は、過度の分離自体も汚く感じ始める可能性があるというあなたの質問の主張にも同意するためです。

そうは言っても、私は分離に反対しているわけではありません。 anyブランケットルールのブラインドアプリケーションに反対するだけです。

分離と再利用性

最初に、私はあなたに同意します。私は同じことを何度も繰り返すのが好きではありません。多くの尊敬される同僚がすべてを分離しておくことを主張しているのを見ますが、私の仕事が他の何よりもコピー/貼り付けで構成されている程度に起こることもわかります再利用性の対比。
これを入力しているときに、コピーペーストの最中に新しい機能を追加し、ファイルをコピーして言及を置き換えて、文字どおりエンタープライズ機能全体（単体テストと統合テストを含む7つのプロジェクト）を作成しましたof Foo by Bar。

しかし、私はなぜそれが一般的に推奨されるのか理解しています。たまたま同じプロパティ/動作を持つ2つのビューモデルが存在する可能性があるからといって、これらのビューモデルがそのように永遠にとどまることを意味するわけではありません。
ビューモデルの1つを変更する必要があるポイントに到達すると、すでにすべてを分割していることの利点に気づきます。

すでに2つの個別のビューモデルを作成している場合は、調整する必要があるビューモデルを調整するだけです。
2つの個別のビューモデルをまだ作成していない場合は、それらを分離するために労力を費やす必要があります。その後、調整に必要なビューモデルの調整を開始できます。

プログラマーは時間の経過とともに物事を忘れる傾向があり、セットアップ中に数か月前にビューモデルを分離した場合（またはしない場合）、今までにアプリケーション構造の一部を忘れている可能性があります。つまり、ビューモデルを分離する必要があるとき（今は）、どこにも忘れていないことを確認するのに苦労するかもしれません。

上記のパラグラフは、すべてをセットアップするときに分離タスクを実行していることを意味するため、初期の分離を明らかに支持します。これは、最高の実用的な知識を持っている時点です（物事を忘れてしまう将来とは対照的です）。）。

将来の変化に対するギャンブル

それは本質的に推測ゲームです：これらのビューモデルは時間の経過とともにバラバラになりますか？

どちらの場合でも、最終的に正しい場合は、適切な労力を費やします。そこには議論はありません。しかし、あなたが間違っている場合、間違っていることの結果は比較できません：

ビューモデルを分離する必要があり、それを行わなかった場合。その結果、複雑な作業になる可能性のある追加のモデルを配線する必要があります。
ビューモデルを分離する必要はないが、とにかく分離した場合。その結果、開発時間の一部が失われ、2つのファイルがコピー/貼り付けされます。

数学はここで明らかです。間違っていることの結果は、離れていないのに間違っていた場合よりも時間がかからないので、分離の側でエラーを起こす方が良いです。
しかし、そしてこれは重要ですが、多くの開発者が忘れていると感じています：

すべてを分離するということは、包括的なアプローチであるため、これをすべて（100％）に対して行うことを意味します。
すべてを分離するのではなく、必要なときにのみ分離することは、ケースバイケース（100％未満）で実行できます。

今日、クラスの100％を（早期に）分離する必要があるのではなく、クラスの1％を（遅延して）分離するだけで済む場合は、数学が変化することを意味します。
早い分離は遅い分離より明らかに速いです。ただし、100の早期分離は、おそらく1の遅い分離よりも速くなりません。

ここでより良い選択は最小の開発時間（のあるものです：注：将来の開発時間に影響を与えるため、ここでコードの複雑さを考慮に入れてください）。
ここには普遍的に正しい答えはありません。それは、コードベースの複雑さと、予想（将来の変更を加える必要がある）が間違っている確率に大きく依存します。

おわりに

開発者が手抜きをして、メンテナンス不可能なコードベースの混乱に終わる前例はたくさんあります。これは非常に一般的なことであり、開発者に対する優れた実践圧力が非常に高い理由でもあります。これは、「プロ分離」論の根源でもあります。メンテナンス不可能な混乱を防ぎ、将来のメンテナンスで開発時間が長くなるのを防ぎます。

ただし、他の方法でエラーが多すぎることも問題です。開発者に直接影響を与えない問題であるため、実際には同じスポットライトが当てられません（開発時間を長くするだけであり、製品所有者の問題です。製品開発者）。

答えは、人生のすべてのものと同じように、正しいバランスを見つけるです。どちらかの側で問題が発生するため、スケールの両側で盲目的にエラーを発生させないでください。代わりに、現在の状況を確認し、オプションを評価して（過去の経験を考慮に入れて）、総開発時間（将来のメンテナンスを含む）に予想される影響が最も小さいオプションを選択してください。

ブランケットルールを盲目的に適用しないでください。ルールを適用する前に、現在のコンテキストに対するルールの適用性を常に評価してください。