web-dev-qa-db-ja.com

委任、構成、および集約の区別（Java OO Design）

私は、委任、構成、および集約を相互に区別し、一方を他方よりも使用するのが最適な場合を識別する継続的な問題に直面しています。

私はJava OO Analysis and Designブックを参照しましたが、私の混乱はまだ残っています。主な説明はこれです：

委任：オブジェクトが変更せずに別のオブジェクトの機能をそのまま使用する場合。

構成：私のオブジェクトは他のオブジェクトで構成されており、オブジェクトが破棄された後に存在することはできません。

Aggregation：私のオブジェクトは、私のオブジェクトが破壊された後でも生き続けることができる他のオブジェクトで構成されています。

各ケースを示すいくつかの簡単な例と、それらの背後にある理由を示すことは可能ですか？私のオブジェクトが別のオブジェクトへの参照を持つだけでなく、これらの例は他にどのように実証できますか？

javaoopaggregationcompositiondelegation
54
denchr

オブジェクトは、3つの場合すべてで別のオブジェクトを参照します。違いは、参照オブジェクトの動作やライフサイクルにあります。いくつかの例：

  1. 構成：家には1つ以上の部屋が含まれています。ルームはハウスなしでは存在しないため、ルームの寿命はハウスによって制御されます。

  2. 集約：ブロックから構築されたおもちゃの家。分解できますが、ブロックは残ります。

  3. 委任：上司からコーヒーをもらうように頼まれましたが、代わりにインターンがやってくれました。委任は関連付けの一種ではありません（構成/集約のような）。後者の2つは、スタックオーバーフローで説明されています 多くの回数

コメントでは、各ケースで実装がどのように異なるかを尋ね、すべてのケースで関連オブジェクトのメソッドを呼び出すことを観察します。いずれの場合にも、次のようなコードがあることは事実です

myRoom.doWork();

myBlock.doWork();

myMinion.doWork();

しかし、違いは関連するオブジェクトのライフサイクルとカーディナリティにあります。

コンポーネントの場合、ハウスが作成されるとルームが存在します。したがって、それらをHouseのコンストラクターで作成できます。

アソシエーション（私はタイヤと車を使用します）の場合、車はコンストラクターにタイヤを追加するかもしれませんが、後でタイヤを取り外して変更したい場合があります。したがって、次のようなメソッドもあります

 removeTyre(FrontLeft)
 addNewTyre(aTyre, BackRight)

そしてaTyreオブジェクトはFactoryから来た可能性が非常に高い-Carのメソッドのいずれでもnewしなかった。

委任の場合、委任を保持するためのメンバー変数さえない場合があります

 resourcingPool().getIntern().getCoffee(SkinnyLatte, workstation 7);

オブジェクト間の関係は、インターンがコーヒーを取得している間のみ持続します。その後、リソースプールに戻ります。

51
ChssPly76

あなたの本は非常に良い説明をしているので、いくつかの例を詳しく説明します。

委任： 私のオブジェクトが別のオブジェクトの機能を変更せずにそのまま使用する場合。

クラスは論理的に大きくする必要がある場合があります。しかし、大きなクラスは良いコーディングの習慣ではありません。また、クラスの一部の機能が複数の方法で実装できる場合がありますが、それをいつか変更したい場合があります。


class FeatureHolder {
 void feature() {
  // Big implementation of the feature that you dont want to put in the class Big
 }
}

class Big {
 private FeatureHolder FH = new FeatureHolder();

 void feature() {
  // Delegate to FeatureHolder.
  FH.feature();
 }

 //.. Other features
}

上記の例から、Big.feature（）はFHの機能を変更せずにそのまま呼び出します。このように、クラスBigには機能の実装（労働の分離）を含める必要はありません。また、feature（）は「NewFeatureHolder」などの他のクラスによって異なる実装を行うことができ、Bigは代わりに新しい機能ホルダーを使用することを選択できます。

組成： 私のオブジェクトは他のオブジェクトで構成されており、これらのオブジェクトは破棄されたガベージコレクションの後に存在できません。

集約： 私のオブジェクトは、私のオブジェクトが破壊された後でも生き続けることができる他のオブジェクトで構成されています。

技術的には、構成は「の一部」であり、集約は「参照」関係です。あなたの腕はあなたの一部です。あなたがもう生きていないなら、あなたの腕も死にます。あなたの布はあなたの一部ではありませんが、あなたはそれらを持っています。あなたがゲストとしてできるように、あなたの布はあなたと一緒に行きません。

プログラミングでは、一部のオブジェクトは別のオブジェクトの一部であり、それなしでは論理的な意味を持ちません。たとえば、ボタンはウィンドウフレームに構成されます。フレームが閉じられている場合、ボタンにはもう配置する理由がありません（合成）。ボタンには、データベースへの参照が含まれる場合があります（データの再読み込みなど）。ボタンを削除しても、データベースはまだ存在する可能性があります（集約）。

私の英語で申し訳ありませんが、これが役立つことを願っています

17
NawaMan

1）委任：運転手の車の例。男が車を買いました。しかし、その男は車を運転することを知りません。そのため、彼は車の運転を知っているドライバーを任命します。そのため、Manクラスは車を使用して交通機関を実行したいと考えています。しかし、車との相互作用機能/互換性はありません。そこで彼は、男性クラスと互換性のあるドライバーである車と互換性のあるクラスを使用します。ドライバーが男の言うことを理解できると仮定する

2）構成：車のシミュレーションは日常的な例です。車を動かすために、ホイールが回転します。 wheelクラスを使用するcarクラスは、move関数の一部として機能を回転させます。ホイールはcarの一部です。

3）集計：車とその色。車のクラスオブジェクトフェラーリには、色のクラスオブジェクトが赤になります。ただし、赤色の指定でユーザー検索が行われる場合、カラークラスオブジェクトredは個々のクラスとして存在できます。

1
Vishwamithra