クラスがロジックのない情報のコレクションのみであることが適切ですか？

私はクラス持っていると言うPersonのインスタンス変数を持っているage、weightとheight、と別のクラスFruitのインスタンス変数を持っているsugarContentとしますtexture。Person一方、クラスは、セッターとゲッター保存メソッドを持たないFruitクラスは、セッターとゲッターの両方があるとのようなロジック・メソッドをcalculateSweetness。Fruitクラスは、クラスよりも実践的なクラスのタイプですPerson。つまり、Personクラスはあまり目的を持っていないようです。Fruitクラスはデータを整理し、実際にはロジックのメソッドを含みますが、データを整理するためだけに存在します。

あなたの人が実際に何もしていない場合は、それにアクションを実行する必要はありません。データを収集するだけのクラスを持つことが可能であり、その場合、このデータを操作するクラスが存在します。あなたのケースでは、あなたは一人の人には何のアクションも持っていないかもしれませんが、CalculateAverageHeight（）のように人のグループにアクションがあるかもしれません。この場合、アクションなしのPersonのみを持ち、次にこれに取り組む別のクラス（友達かもしれません）を持つことは理にかなっています。

すべてのクラスに何らかのロジックが必要であるというルールを付けるのは困難です。一般に、ロジックのないクラスはAnemicDomainModelと見なされます 。

それでも、関連情報が大きくなっている場合は、データを整理することをお勧めします。たとえば、この場合、関係のない多くのコレクションよりも、まだPersonのコレクションが必要な場合があります。

DataTransferObjectは何のロジック、データのみを持っていないクラスの良い例です。それが目的です。これは、すべてのクラスが内部状態に影響を与えるビジネスロジックを実装する必要があるという一般的なルールの例外です。多くの場合、内部ロジックが外部ロジックによって変更されるクラスは、デザインのにおいがします。これは必ずしも間違っているわけではありませんが、ほとんどの場合、リファクタリングを検討する必要があります。

質問を逆にして、反対側を見てください。明らかに一緒に属している情報のコレクションがある場合、そのクラスに追加できるメソッドがないという理由だけでそれを分けておくべきですか？クラスを正当化するためだけに任意のメソッドを発明することを強いられるべきですか？

モデルはそれ自体に終わりはありません。おそらく将来的に必要になると推測するのではなく、プログラムで本当に必要なときに機能をクラスに追加する必要があります。したがって、ある時点で「実際の」メソッドのないクラスが存在することは当然であり、後でクラスにメソッドを追加することが理にかなっていると判断した場合は、まさにそれを行います。モデルの品質は「ここにメソッドはあり、そこにメソッドはありません」では測定されません。品質は「アプリケーションに実際に必要なすべてのメソッドがあるか」で測定されます。

例えば、のようなバージョンでアプリケーション1.0ニーズが何かcalculateSweetnessのためにFruit、しかしに何の操作んPerson属性の取得と設定を除いては、その後、あなたのモデルは、正確に、クラス内の任意のロジックを持っていないことにより、それを反映しないはずですPerson。バージョン2.0では、ロジックを追加することも理にかなっている可能性があるためPerson、その時点で問題のメソッドを追加します。

これは言語と言語の使い方に依存すると思います。

自明なケースでは、一部の言語はクラスにあるすべてのものを要求します。たとえば、定数のコレクションはクラスに移動する必要があり、クラスがロジックを持っている場合と持たない場合があります。他の言語では、代わりに名前空間になる可能性があります。

マルチパラダイム言語では、デザインをどのパラダイムに準拠させたいかによっても異なります。CalculateAverageHeight（）の例を借用します。これは、PersonCollectionクラスに常駐しているはずですが、これはOOPソリューションを前提としています。より機能的な設計では、たとえばC＃のように、ジェネリックコレクションで高次関数を使用できます。

List<Person> personList = GetListOfPeople();
personlist.Average(p => p.Height);

そして、ロジックはPersonCollection内にないか、静的にPerson内にさえありません。実際、より高次の関数と一般的なデータタイプは、ロジックが特定のデータモデルよりも高い抽象化レベルで動作しているため、一般にデータのバッグであるオブジェクトで終わる可能性が高いことを意味します。

あなたが話しているのはPOD（プレーンな古いデータ）のようです。さまざまな言語がこれらをさまざまな方法で表すことができます。たとえば、パブリックメンバーを持つクラスや、C ++のパブリックメンバーのみを持つ構造体などです。

データを編成することは、クラスが存在するための完全に正当な理由です-多くの場合、コードをよりクリーンで読みやすくすることができます。 std::pairC ++のSTLにのみデータを整理するために存在する構造の良い例である-という名前の任意のタイプの2つの値を保持し、単に構造体firstとsecond。おそらく、STL全体で最も有用なクラスの1つ（とにかく私の意見では:)）