1

特定の言語ではなく、一般的な OOP に関する質問があります。私は単純なアプリケーション (Java で) を試していて、実際のシナリオのようにモデル化しようとしていました。リファクタリング中に、1 つのメンバーとオーバーライドされた equals と hashcode を持つ単純なオブジェクトを思いついたことに気付きました。

私の質問は....そのようなオブジェクトを持つのは悪い習慣ですか(ブログなどへの参照は大歓迎です)

4

4 に答える 4

1

この場合は違います。これが、Java のハッシュ データ構造でオブジェクトの動作を再定義する唯一の方法だからです。

他のケースでは、意味があるかどうかに応じて、より良い方法と悪い方法があるかもしれません。たとえば、キュ​​ー内のオブジェクトの順序を変更したい場合、Comparator継承してオーバーライドするよりもカスタムを実装することを好みます。compareToメソッド、特に私の新しい比較ルーチンがオブジェクトにとって「自然」ではない場合。

すべてのデザイン パターンには、適切な場合と不適切な場合があります。

于 2011-06-22T07:50:52.073 に答える
1

短い答え:

そのようなオブジェクトを持つことは悪い習慣ですか?

必ずというわけではありませんが、文脈によって異なります。

より長い答え:

特定の言語ではなく、一般的な OOP に関する質問があります。私は単純なアプリケーション (Java で) を試していて、実際のシナリオのようにモデル化しようとしていました。

あなたがすべきであると述べている規則は本当にありません。実際、ボブ・マーティンおじさんのように、この発言に眉をひそめている人をかなり多く知っています。「現実世界のシナリオ」をモデル化することよりも、ビジネス プロセスをモデル化することが重要です。私は過去にそれを試したことがありますが、現実世界のようにすべてを厳密にモデル化しようとしても、まったく、またはほとんどメリットがないことがわかりました。どちらかといえば、アプリケーションが複雑になり、ソフトウェアが複雑になればなるほど保守が難しくなると思います。

リファクタリング中に、1 つのメンバーとオーバーライドされた equals と hashcode を持つ単純なオブジェクトを思いついたことに気付きました。

@Arseny が既に述べたように、ValueObject はよく知られた動作方法ですが、通常、コードを記述するときにそれらの多くを使用することはありません。動作しないオブジェクトがいくつかある場合、これはいわゆるAnemic Domain Modelを示している可能性があり、注意する必要があります (より複雑で明らかな利点はありません)。

「間違っている」かどうかを確認できます (もちろん、変数の値は「間違っています」): 共同作業者が ValueObject で何をしているかを確認し、実際に属する計算に似たものがそこにあるかどうかを確認します。オブジェクト自体に。

ただし、これが何の動作も含まない数少ないオブジェクトの 1 つである場合: まあ、そうです。おそらくそれについて心配する必要はありません。ただし、回答で決定的なコードを確認する必要があります。

于 2011-06-22T07:56:46.063 に答える
0

通常、行動のない物体を持っていることは匂いと見なされます。その理由は、動作がない場合はオブジェクトではないためです。クラスを設計するときは、「クラスは何を担当しているのか」などの質問をする必要があります。動作がない場合、これは答えるのが難しい質問です。

これがNullObjectパターンのようなものであるというまれな例外。

http://en.wikipedia.org/wiki/Null_Object_pattern

あなたのクラスのメンバーは実際には別のクラスのメンバーでなければならないかもしれません。また、クラスにまだ発見していない機能がある可能性もあります。また、プリミティブ型が行う場合、概念を重視しすぎている可能性もあります。

OOシステムを設計するためのテクニックはたくさんありますが、これがオリジナルの1つです:http: //en.wikipedia.org/wiki/Class-responsibility-collaboration_card

于 2011-06-22T08:37:00.540 に答える
0

いいえ、悪くありません。広く使われているValue Objectパターン witch やDTOパターンもあります。

于 2011-06-22T07:44:28.027 に答える