集計と構成

OOPの構成は理解していますが、Aggregationが何であるかを明確に把握することはできません。誰か説明できますか？

簡単なルール：

1. A「所有」B =構成：Bは、Aのないシステムでは意味も目的もない
2. A「使用」B =集約：BはAとは独立して（概念的に）存在します

例1：

会社は人の集合体です。会社はアカウントの構成です。会社がビジネスをやめると、そのアカウントはなくなりますが、その人は存在し続けます。

例2：（非常に単純化）

テキストエディタは、バッファ（構成）を所有しています。テキストエディターはファイル（集計）を使用します。テキストエディタが閉じられると、バッファは破棄されますが、ファイル自体は破棄されません。

http://en.wikipedia.org/wiki/Object_compositionから

集約は、所有権を意味しないという点で通常の構成とは異なります。構成では、所有オブジェクトが破壊されると、含まれるオブジェクトも破壊されます。集約では、これは必ずしも真実ではありません。たとえば、大学にはさまざまな学部（化学など）があり、各学部には多数の教授がいます。大学が閉鎖されると、学部はもはや存在しなくなりますが、それらの学部の教授は存在し続けます。したがって、大学は学部の構成として見ることができますが、学部には教授の集合体があります。さらに、教授は複数の学部で働くことができますが、学部は複数の大学に所属することはできません。

したがって、構成と所有関係がある場合、所有者が所有者である場合、所有オブジェクトも破棄されます-集約（および含まれるオブジェクト）は独立して存在できます。

-

更新：謝罪-この答えは後知恵では単純すぎます。

c.battは彼の答えに優れた定義を提供します集約を構成対

単一の説明はありません。異なる著者は、集約によって異なることを意味します。ほとんどは、それによって特定のものを意味するものではありません。

• 作曲は協会です

• 集約は関連付けです

• 構成は強力な関連付けです（含まれているオブジェクトの寿命がコンテナオブジェクトに完全に依存している場合、それは強力な関連付けと呼ばれます）

• 集約は弱いアソシエーションです（含まれるオブジェクトの寿命がコンテナオブジェクトに依存しない場合、弱いアソシエーションと呼ばれます）

例：

class Contained {
    public void disp() {
        System.out.println("disp() of Contained A");
    }
}

public class Container {
    private Contained c;

    //Composition
    Container() {
        c = new Contained(); 
    }

    //Association 
    public Contained getC() {
        return c;
    }

    public void setC(Contained c) {
        this.c = c;
    }     

    public static void main(String[] args) {
        Container container = new Container();
        Contained contained = new Contained();
        container.setC(contained);
    } 
}

構成（混合）は、単純なオブジェクトまたはデータ型をより複雑なものに結合する方法です。コンポジションは、多くの基本的なデータ構造の重要な構成要素です

集約（コレクション）は、所有権を意味しないという点で通常の構成とは異なります。構成では、所有オブジェクトが破壊されると、含まれるオブジェクトも破壊されます。集約では、これは必ずしも真実ではありません

╔═══════════╦═════════════════════════╦═══════════════════════╗
║           ║       Aggregation       ║      Composition      ║
╠═══════════╬═════════════════════════╬═══════════════════════╣
║ Life time ║ Have their own lifetime ║ Owner's life time     ║
║ Relation  ║ Has                     ║ part-of               ║
║ Example   ║ Car has driver          ║ Engine is part of Car ║
╚═══════════╩═════════════════════════╩═══════════════════════╝

両方ともオブジェクト間の関係を示し、強度のみが異なります。

2つのクラス間の異なる種類の依存関係のUML表記

構成：エンジンは車の一部であるため、それらの間の関係は構成です。Javaクラス間での実装方法を次に示します。

public class Car {
    //final will make sure engine is initialized
    private final Engine engine;  

    public Car(){
       engine  = new Engine();
    }
}

class Engine {
    private String type;
}

集約：組織には従業員として人がいるため、それらの間の関係は集約です。Javaクラスの観点から見た場合、次のようになります。

public class Organization {
    private List employees;
}


public class Person {
    private String name;   
}

ソース

集約はビー玉の袋のような単純なコレクションです

構成は、ボックスのヒンジのような内部/機能の依存関係を意味します

車は乗客を集めます。車の機能を損なうことなく乗り降りする

タイヤはコンポーネントです。1つを削除すると、車は正しく機能しなくなります

[注：スペアタイヤは集合体です！]

私は常に構図を「必要」と見なします。つまり、車にはエンジンが必要であり、集約は「目的に関連するもの」と見なします。そのため、車の例えにとどまると、私の集合は、車と乗客を結びつけることを含む旅を表すことになります。旅行は車や乗客を所有するものではなく、特定のシナリオに関連するデータを集約しています。旅が完了すると、車と乗客が進みます。車が終了すると、通常、車とエンジンが一緒に破壊されます。

意味的には、すべてのセットはサブセットで構成されていますよね？したがって：

• 集合は、それらのサブセットが父親セットとは独立して存在する場合です。モニターを別のコンピューターに接続するためにコンピューターから取り外すことができるため。

• 構成は、これらのサブセットが父親セットの存在に依存する場合です。葉は木の一部であり、肝臓は体の一部です。

これらの概念は、2つのオブジェクトまたはクラス間の依存関係の種類について概念的に説明しています。プログラムで直接、集約で、親オブジェクトが破棄されるとき、集約オブジェクトも破棄される必要があります。コンポジションの同じシナリオでは、複合の息子オブジェクトが存続し、その後父オブジェクトが分配されます。

この簡単な例はどうですか：

オブジェクトの配列はコンポジションです。オブジェクトへのポインタの配列は集約です。

最初のものを削除すると、その内容は消えます。一方、2番目のメソッドは、ポインターが削除されるときに各オブジェクトを削除する特定のメソッドがない限り、そのメンバーの存在に影響を与えずに消えることがあります。