UIとロジックを別々のクラスに配置する必要がありますか？
私は現在、趣味のプロジェクトに取り組んでいます。このプロジェクトを使用して、Android/Javaプログラミングおよびプログラミング全般について詳しく学びます。最近、jUnitをプロジェクトに統合することにしました。そこに入るだけで大した問題はありませんでしたが、実際に使用することには問題がありました。ユニットテストは、メソッド（またはコンポーネント）が行うことになっていることの定義である必要があることを読みました。そのユニットテストは、優れた、または少なくともより良いコードを書くことを強制します。
しかし、いくつかのロジックをテストするための最初の単体テストを書いた瞬間に問題が発生し始めました。テストしたいメソッドは論理的な作業のみを行い、UIは何も行われず、結果は後で使用するために変数に保存されるだけです。しかし、同じクラスで、最初のメソッドがうまくいったことを表示するメソッドがあります。そしてjUnitはそれが好きではないようです。 （もちろん）UIインポートが必要な2番目の方法では、jUnitは「Androidコンテキストクラス」を知らないと不平を言います。これまでは、コンポーネントの論理部分とUI部分を1つのクラスに配置するが、メソッドを分離することは簡単に理解でき、許容できる方法だと思っていました。しかし、今、「jUnitはあなたに良いコードを書くことを強制する」ので、私はこれについてはるかに確信が持てません。
それで、UIと論理パーツ1つのコンポーネント用を別のクラスに配置する必要がありますか？それらは互いに依存し、UIメソッドは論理メソッドからの値を必要としますが、論理メソッドはUIメソッドなしでは計算値を使用して何もできません。しかし、他の誰かがこれについて別の考えを持っているかもしれないので...そして、その「他の誰か」は、おそらく結局私のコードを理解する必要がある人です。
Model-View-Controller 、 Model-View-Presenter および Model-View-ViewModel のようなUIデザインパターンは、定期的にメカニズム（つまり、個別のクラス）を提供します既に引用したのと同じ理由で、UIの表面とそれを管理するクラスの間で 懸念の分離 を許可します。
これが趣味のプロジェクトであれば、ここで学ぶ素晴らしい機会があります。
私はあなたがそれがそうであるように設計し続けることを勧めます。ロジックをUIから移動しないでください。まったく分離しないでください。
代わりに、同じことを行う別のプロジェクトを開始します。今回は、UIとロジックを分離します。両方のプロジェクトの動作を同じに保ちます。
分離された設計は、同じ動作に対してはるかに多くの作業であることがわかります。これは常に本当です。したがって、この分離ビジネスはあなたの時間の腰だと思うかもしれません。物語がここで終わったら、それはそうです。
次に、まったく新しいGUIを設計します。多分別のIDEです。多分テキストベースのバージョンを作る。さて、これら2つのプロジェクトのうち、これらの変更を行う方が簡単なのはどれですか。
ハードウェアではなくソフトウェアの問題を解決するポイントは、ソフトウェアの変更が簡単であることです。私がそれを解決するために電気技術者を雇ったかもしれないと私に思わせるようなスタイルでコードを書かないでください。
クラスを分けるのではなく全体を書き直すのが良いアイデアかどうかはわかりません...私はこのプロジェクトに約1年半取り組んできたので、コピーと貼り付けのどちらかになります。古いプロジェクトから、またはwhoooooollleeeたくさんの仕事。 – Namnodorel
プロジェクトがそれほど大きい場合は、小さな探索的プロジェクトを書く方が賢明かもしれません。小さな機能を取り上げて、趣味のプロジェクトの1つの画面、または最終的にはその一部となる画面を例にして、それの個別のバージョンを作成します。このようにすると、アイデア全体が気に入ったかどうかを知らせるために、変換全体がフィードバックを受け取るのを待つ必要がなくなります。これは簡単ではないことに注意してください。慣れ親しんだ方法でコーディングすることになります。この種のコードを読むことに慣れるには、おそらく時間がかかるでしょう。
[〜＃〜] mvc [〜＃〜] を検討するのは良いことですが、これらの懸念がどのように話し合うかについてではなく、3つの懸念を分離することだけのため、明確な計画は得られません。その他。また、想定に注意してください。分離は、3つのクラスに分類されるだけではありません。 3つの問題のそれぞれの小さな部分を処理するクラスを作成できます。
observer pattern を見て、それらの間で話し合うイベントの方法を確認します。オブザーバーパターンは、他の何よりも イベントドリブンプログラミング について多くを教えてくれました。
n層アーキテクチャ を見て、複数のクラスを問題の層に分離する方法を確認してください。 ports and adapters と clean architecture のこれらの行に沿った良いレッスンも。
ここで学ぶことはたくさんあり、落ちてあきらめる場所はたくさんあります。難しいからといって止めないでください。しかし、信仰でそれを使用するだけではありません。それぞれのアイデアに価値があることを証明してください。
TL; DR
はい、そうすべきです。
- クラスの変更理由は1つだけです。
- ロジックを調整する必要がある場合、クラスには変更する理由があります
- UIを変更する必要がある場合、クラスに変更する別の理由があります
- したがって、クラスには2つの理由があります。
- 多くの理由 のため、それは望ましくありません。
- それを単一責任原則といいます。
- SRPに従わない場合の問題の1つは、ビジネスロジックのテストが難しいことです（何が問題か）。
- 同じクラスにUIロジックとビジネスロジックを含めることのもう1つの欠点は、変更されていない（または変更されていないと思われるもの）をテストする必要があることです。クラスを編集してUIの色を変更する場合、何かを壊した場合に備えて、もう一度クラスをテストする必要があります（ソフトウェアはそのようなものです）。 UIとBLを分離している場合は、BLをテストする必要はありません。ビジネスロジッククラスは変更されていません。
とは言っても、それが趣味のプロジェクトであれば、保守性とテスト容易性についてあまり心配する必要はありませんが、jUnitをカクテルに入れているという事実は、単なる趣味よりも多くを学び、より良いことをしたいということを示しています。したがって、ソフトウェアの保守性とテスト性を高める原則の適用を開始します。 jUnitはプロフェッショナルツールであるため、いくつかの標準が必要です。