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


8

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


それで、人は身長、体重、そして/または身長のセッターを持っていますよね?これらの属性をどこかに操作するロジックがない限り、セッターは無意味です。そのロジックは正しいクラスですか?
から来る

@COMEFROM:あなたは正しい、それはここで尋ねられる質問です。ただし、情報システムでは、実際のロジックなしで属性がそのシステムに格納、表示、およびレポートされることが一部の属性の目的全体であることは珍しくありません(その属性を実際に使用するビジネスプロセスは情報システムの外部に存在する場合があります)。
Doc Brown、

@Doc Brown:わかって同意します。ロジックのないクラスには何も問題はないと思いますが、そのようなクラスにセッターがあると、少し怪しいです。これらのセッターが必要な場所を確認します。あなたが書いたように:必要に応じてクラスに機能を追加します。セッターは機能です。
から来

回答:


8

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


1
適切に設計されたOOPシステムでデータとロジックを異なるクラスに分割することが「一般的」だったとは言えません。あなたの例では、私はオブジェクトのコレクションを受け取るCalculateAverageHeight()静的メソッドでPersonあると期待していPersonます。こうCalculateAverageHeight()することで、の個々のインスタンスに適用できない場合でも、Person操作対象のデータに近づけることができます。
TMN

1
@TMN-一般的な言葉で申し訳ありません。一般的ではありませんが、可能です。平均身長の計算が人物クラスと密接に関連していることには同意しません。HighDensityArea()という別の関数について考えてみましょう。これは、人口のほとんどが居住するエリアを検出します。この関数は、個人の住所フィールドのみを必要とします。これをPersonクラスと密接にバインドする必要はありません。
Manoj R

4

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

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


3
私は、この(AnemicDomainModel)が常に真であるとは思わないだけであなたは何のロジックを持っていないので。実際、多くの基本的なEntityタイプはこれだけです:1つの特定のオブジェクトに関連するすべての情報のコレクションですが、特定のロジックが接続されていません。Personは単に...ですが、Personを表すクラスが必要ではないと主張するのは難しいでしょう。
Peter Rowell

@ Peter Rowell:J2EEのエンティティ(bean)が記事で特別に言及されています。
Jayan


Anemic Domain Modelの適​​切に機能する定義は、オブジェクト内のデータ整合性を適用するためにビジネスルールが存在する必要があるドメインですが、それらのルールは同じオブジェクト内にカプセル化されていません。オブジェクトがいない場合は必要な内部的に一貫性のある状態を維持するためのロジックを、そのようなお金のパターンとして、それはいけませんしているロジックを言いました。ただし、請求書に小計データプロパティがあり、それが常にラインアイテムの拡張コスト(それぞれが単価*数量)の合計である必要がある場合、これらのプロパティを計算し、直接設定することはできません。
キース

このようなクラスがたくさんある場合、問題があります。ただし、一部のデータ項目を整理したいだけの場合もありますが、他の場所では意味をなさないメソッドはありません。
Loren Pechtel

3

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


3

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


2

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

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


1

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

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

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

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

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


1

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.