Apa perbedaan antara asosiasi, agregasi dan komposisi?

Apa perbedaan antara asosiasi, agregasi, dan komposisi? Tolong jelaskan dalam hal implementasi.

Untuk dua objek, Foodan Barhubungannya dapat didefinisikan

Asosiasi - Saya memiliki hubungan dengan suatu objek. FoomenggunakanBar

public class Foo { 
    void Baz(Bar bar) {
    } 
};

Komposisi - Saya memiliki objek dan saya bertanggung jawab untuk masa pakainya. Ketika Foomati, begitu jugaBar

public class Foo {
    private Bar bar = new Bar(); 
}

Agregasi - Saya memiliki objek yang saya pinjam dari orang lain. Ketika Foomati, Barbisa hidup terus.

public class Foo { 
    private Bar bar; 
    Foo(Bar bar) { 
       this.bar = bar; 
    }
}

Saya tahu pertanyaan ini ditandai sebagai C # tetapi konsepnya adalah pertanyaan yang cukup umum seperti pengalihan ini di sini. Jadi saya akan memberikan sudut pandang saya di sini (sedikit bias dari sudut pandang java di mana saya lebih nyaman).

Ketika kita memikirkan sifat berorientasi Objek, kita selalu memikirkan Obyek, kelas (objek cetak biru) dan hubungan di antara mereka. Objek saling berhubungan dan berinteraksi satu sama lain melalui metode. Dengan kata lain objek dari satu kelas dapat menggunakan layanan / metode yang disediakan oleh objek dari kelas lain. Hubungan semacam ini disebut sebagai asosiasi. .

Agregasi dan Komposisi adalah himpunan bagian dari asosiasi yang berarti mereka adalah kasus asosiasi tertentu.

• Baik dalam agregasi dan komposisi objek dari satu kelas "memiliki" objek dari kelas lain .
• Tetapi ada perbedaan yang halus. Dalam Komposisi objek kelas yang dimiliki oleh objek kelas yang dimilikinya tidak dapat hidup sendiri (Juga disebut "hubungan kematian"). Ia akan selalu hidup sebagai bagian dari objek yang dimilikinya, di mana seperti dalam Agregasi objek dependennya berdiri sendiri dan dapat eksis bahkan jika objek memiliki kelas sudah mati.
• Jadi dalam komposisi jika memiliki objek adalah sampah yang terkumpul, objek yang dimiliki juga akan menjadi yang bukan agregasi.

Bingung?

Contoh Komposisi : Pertimbangkan contoh Mobil dan mesin yang sangat spesifik untuk mobil itu (artinya tidak dapat digunakan di mobil lain). Jenis hubungan antara kelas Car dan SpecificEngine disebut Komposisi. Objek dari kelas Mobil tidak dapat ada tanpa objek dari kelas SpecificEngine dan objek dari SpecificEngine tidak memiliki arti tanpa kelas Car. Singkatnya, kelas Mobil semata-mata "memiliki" kelas SpecificEngine.

Contoh Agregasi : Sekarang pertimbangkan kelas Mobil dan Roda kelas . Mobil membutuhkan objek Roda berfungsi. Berarti objek Mobil memiliki objek Roda tetapi kita tidak dapat mengatakan objek Roda tidak memiliki arti tanpa Obyek Mobil. Ini dapat digunakan di Sepeda, Truk atau Objek Mobil yang berbeda.

Ringkasnya -

Singkatnya asosiasi adalah istilah yang sangat umum digunakan untuk mewakili ketika kelas menggunakan fungsionalitas yang disediakan oleh kelas lain. Kita mengatakan itu komposisi jika satu objek kelas induk memiliki objek kelas anak lain dan bahwa objek kelas anak tidak dapat ada secara bermakna tanpa objek kelas induk. Jika bisa maka itu disebut Agregasi.

Lebih detail di sini. Saya penulis http://opensourceforgeeks.blogspot.in dan telah menambahkan tautan di atas ke posting yang relevan untuk lebih banyak konteks.

Asosiasi adalah konsep hubungan yang digeneralisasi. Ini mencakup Komposisi dan Agregasi.

Komposisi ( campuran ) adalah cara untuk membungkus objek atau tipe data sederhana menjadi satu kesatuan . Komposisi adalah blok bangunan penting dari banyak struktur data dasar

Agregasi ( pengumpulan ) berbeda dari komposisi biasa karena tidak menyiratkan kepemilikan. Dalam komposisi, ketika benda yang dimiliki dihancurkan, demikian pula benda yang terkandung. Secara agregasi, ini belum tentu benar.

Keduanya menunjukkan hubungan antara objek dan hanya berbeda dalam kekuatannya.

Trik untuk mengingat perbedaan: memiliki A - A ggregation dan O wn - c O mpositoin

Sekarang mari kita amati gambar berikut

Analogi:

Komposisi : Gambar berikut adalah komposisi gambar yaitu menggunakan gambar individu membuat satu gambar.

Agregasi : koleksi gambar di satu lokasi

Misalnya, universitas memiliki berbagai departemen, dan setiap departemen memiliki sejumlah profesor. Jika universitas ditutup, departemen tidak akan ada lagi, tetapi profesor di departemen tersebut akan terus ada. Oleh karena itu, sebuah Universitas dapat dilihat sebagai komposisi departemen, sedangkan departemen memiliki agregasi profesor. Selain itu, seorang Profesor dapat bekerja di lebih dari satu departemen, tetapi sebuah departemen tidak dapat menjadi bagian dari lebih dari satu universitas.

Ketergantungan (referensi)
Ini berarti tidak ada hubungan konseptual antara dua objek. misalnya referensi objek EnrollmentService objek Student & Course (sebagai parameter metode atau tipe pengembalian)

public class EnrollmentService {
    public void enroll(Student s, Course c){}
}

Asosiasi (memiliki-a)
Ini berarti hampir selalu ada hubungan antara objek (mereka terkait). Obyek pesanan memiliki objek Pelanggan

public class Order {
    private Customer customer
}

Agregasi (memiliki-a + seluruh-bagian)
Jenis asosiasi khusus di mana ada hubungan seluruh-bagian antara dua objek. mereka mungkin hidup tanpa satu sama lain.

public class PlayList{
    private List<Song> songs;
}

Catatan: bagian tersulit adalah untuk membedakan agregasi dari asosiasi normal. Jujur, saya pikir ini terbuka untuk interpretasi yang berbeda.

Komposisi (memiliki-seluruh + kepemilikan + kepemilikan)
Jenis agregasi khusus. An Apartmentterdiri dari beberapa Rooms. A Roomtidak bisa ada tanpa a Apartment. ketika apartemen dihapus, semua kamar terkait juga dihapus.

public class Apartment{
    private Room bedroom;
    public Apartment() {
       bedroom = new Room();
    }
}

Dari pos oleh Robert Martin di comp.object :

Asosiasi mewakili kemampuan satu instance untuk mengirim pesan ke instance lain. Ini biasanya diterapkan dengan pointer atau variabel instance referensi, meskipun mungkin juga diimplementasikan sebagai argumen metode, atau pembuatan variabel lokal.

//[Example:]

//|A|----------->|B|

class A
{
  private:
    B* itsB;
};

Agregasi [...] adalah hubungan keseluruhan / bagian yang umum. Ini persis sama dengan asosiasi dengan pengecualian bahwa instance tidak dapat memiliki hubungan agregasi siklik (yaitu bagian tidak dapat mengandung keseluruhannya).

//[Example:]

//|Node|<>-------->|Node|

class Node
{
  private:
    vector<Node*> itsNodes;
};

Fakta bahwa ini adalah agregasi berarti bahwa instance Node tidak dapat membentuk suatu siklus. Jadi, ini adalah Tree of Nodes bukan grafik dari Nodes.

Komposisi [...] persis seperti Agregasi kecuali bahwa masa hidup 'bagian' dikendalikan oleh 'keseluruhan'. Kontrol ini mungkin langsung atau transitif. Yaitu, 'keseluruhan' dapat mengambil tanggung jawab langsung untuk membuat atau menghancurkan 'bagian', atau mungkin menerima bagian yang sudah dibuat, dan kemudian meneruskannya ke keseluruhan lain yang memikul tanggung jawab untuk itu.

//[Example:]

//|Car|<#>-------->|Carburetor|

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};

Seperti yang dikatakan orang lain, asosiasi adalah hubungan antara objek, agregasi dan komposisi adalah tipe asosiasi.

Dari sudut pandang implementasi, agregasi diperoleh dengan memiliki anggota kelas dengan referensi . Misalnya, jika kelas A mengagregasi objek kelas B, Anda akan memiliki sesuatu seperti ini (dalam C ++):

class A {
    B & element;
  // or B * element;
};

Semantik agregasi adalah bahwa ketika suatu objek A dihancurkan, objek B yang disimpan masih akan ada. Saat menggunakan komposisi, Anda memiliki hubungan yang lebih kuat, biasanya dengan menyimpan anggota berdasarkan nilai :

class A {
    B element;
};

Di sini, ketika sebuah objek A dihancurkan, objek B yang dikandungnya akan hancur juga. Cara termudah untuk mencapai ini adalah dengan menyimpan anggota berdasarkan nilai, tetapi Anda juga bisa menggunakan beberapa penunjuk pintar, atau menghapus anggota dalam destruktor:

class A {
    std::auto_ptr<B> element;
};

class A {
    B * element;

    ~A() {
        delete B;
    }
};

Poin penting adalah bahwa dalam komposisi, objek kontainer memiliki yang terkandung, sedangkan dalam agregasi, referensi itu.

Sungguh menakjubkan betapa banyak kebingungan yang ada tentang perbedaan antara tiga konsep hubungan asosiasi , agregasi dan komposisi .

Perhatikan bahwa istilah agregasi dan komposisi telah digunakan dalam komunitas C ++, mungkin untuk beberapa waktu sebelum mereka telah didefinisikan sebagai kasus khusus dari asosiasi dalam Diagram Kelas UML.

Masalah utama adalah kesalahpahaman yang tersebar luas dan berkelanjutan (bahkan di antara para pengembang perangkat lunak ahli) bahwa konsep komposisi menyiratkan ketergantungan siklus hidup antara keseluruhan dan bagian-bagiannya sehingga bagian-bagian tidak dapat ada tanpa keseluruhan, mengabaikan fakta bahwa ada juga kasus-kasus sebagian-keseluruhan-asosiasi dengan bagian-bagian yang tidak dapat dibagikan di mana bagian-bagian dapat terlepas dari, dan selamat dari kehancuran, keseluruhan.

Sejauh yang saya bisa lihat, kebingungan ini memiliki dua akar:

1. Dalam komunitas C ++, istilah "agregasi" digunakan dalam arti kelas mendefinisikan atribut untuk referensi objek dari kelas independen lain (lihat, misalnya, [1]), yang merupakan arti asosiasi dalam Diagram Kelas UML. Istilah "komposisi" digunakan untuk kelas yang mendefinisikan objek komponen untuk objek mereka, sehingga pada penghancuran objek komposit, objek komponen ini sedang dihancurkan juga.

2. Dalam Diagram Kelas UML, "agregasi" dan "komposisi" telah didefinisikan sebagai kasus khusus asosiasi yang mewakili hubungan sebagian-keseluruhan (yang telah dibahas dalam filosofi sejak lama). Dalam definisi mereka, perbedaan antara "agregasi" dan "komposisi" didasarkan pada kenyataan jika memungkinkan berbagi bagian antara dua atau lebih keutuhan. Mereka mendefinisikan "komposisi" sebagai bagian yang tidak dapat dibagikan (eksklusif), sementara "agregasi" dapat berbagi bagian mereka. Selain itu mereka mengatakan sesuatu seperti berikut: sangat sering, tetapi tidak dalam semua kasus, komposisi datang dengan ketergantungan siklus hidup antara keseluruhan dan bagian-bagiannya sehingga bagian-bagian tidak dapat ada tanpa keseluruhan.

Jadi, sementara UML telah menempatkan istilah "agregasi" dan "komposisi" dalam konteks yang tepat (hubungan sebagian-keseluruhan), mereka belum berhasil mendefinisikannya dengan cara yang jelas dan tidak ambigu, menangkap intuisi pengembang. Namun, ini tidak mengejutkan karena ada begitu banyak properti yang berbeda (dan nuansa implementasi) yang dapat dimiliki hubungan ini, dan pengembang tidak sepakat tentang cara mengimplementasikannya.

Lihat juga jawaban saya yang diperluas untuk pertanyaan SO Apr 2009 yang tercantum di bawah ini.

Dan properti yang diasumsikan untuk mendefinisikan "komposisi" antara objek OOP dalam komunitas C ++ (dan kepercayaan ini masih dipegang secara luas): ketergantungan siklus-hidup run-time antara dua objek terkait (komposit dan komponennya), adalah tidak benar-benar karakteristik untuk "komposisi" karena kita dapat memiliki ketergantungan seperti itu karena integritas referensial juga dalam jenis asosiasi lainnya.

Misalnya, pola kode berikut untuk "komposisi" diusulkan dalam jawaban SO :

final class Car {    
  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

Responden mengklaim bahwa itu akan menjadi karakteristik untuk "komposisi" yang tidak ada kelas lain yang bisa referensi / mengetahui komponen. Namun, ini tentu saja tidak benar untuk semua kasus "komposisi" yang memungkinkan. Khususnya, dalam hal mesin mobil, pembuat mobil, mungkin diimplementasikan dengan bantuan kelas lain, mungkin harus merujuk mesin untuk dapat menghubungi pemilik mobil setiap kali ada masalah dengannya.

[1] http://www.learncpp.com/cpp-tutorial/103-aggregation/

Lampiran - Daftar lengkap pertanyaan yang diajukan berulang kali tentang komposisi versus agregasi di StackOverflow

[ Apr 2009 ]
Agregasi versus Komposisi [ditutup sebagai berdasarkan opini]]
[ Apr 2009 ]
Apa perbedaan antara komposisi dan hubungan Asosiasi?
[ Mei 2009 ]
Perbedaan antara asosiasi, agregasi dan komposisi
[ Mei 2009 ]
Apa perbedaan antara komposisi dan agregasi? [duplikat]
[ Okt 2009 ]
Apa perbedaan antara agregasi, komposisi, dan ketergantungan? [ditandai sebagai duplikat]
[ Nov 2010 ]
Asosiasi vs Agregasi [ditandai sebagai duplikat]
[Agu 2012 ]
Perbedaan implementasi antara Agregasi dan Komposisi di Jawa
[ Feb 2015 ]
UML - asosiasi atau agregasi (cuplikan kode sederhana)

Asosiasi

Asosiasi mewakili hubungan antara dua kelas. Ini bisa searah (satu arah) atau dua arah (dua arah)

sebagai contoh:

1. searah

Pelanggan memesan

2. dua arah

A menikah dengan B

B menikah dengan A

Pengumpulan

Agregasi adalah sejenis asosiasi. Tetapi dengan fitur-fitur tertentu. Agregasi adalah hubungan dalam satu kelas "keseluruhan" yang lebih besar berisi satu atau lebih "kelas" kelas yang lebih kecil. Sebaliknya, kelas "bagian" yang lebih kecil adalah bagian dari kelas "keseluruhan" yang lebih besar. .

sebagai contoh:

klub memiliki anggota

Sebuah klub ("keseluruhan") terdiri dari beberapa anggota klub ("bagian"). Anggota memiliki kehidupan di luar klub. Jika klub ("keseluruhan") mati, anggota ("bagian") tidak akan mati bersamanya. Karena anggota dapat menjadi anggota beberapa klub ("keseluruhan").

Komposisi

Ini adalah bentuk agregasi yang lebih kuat. "Utuh" bertanggung jawab atas penciptaan atau penghancuran "bagian-bagiannya"

Sebagai contoh:

Sebuah sekolah memiliki departemen

Dalam hal ini sekolah ("keseluruhan") akan mati, departemen ("bagian") akan mati bersamanya. Karena setiap bagian hanya dapat dimiliki oleh satu "keseluruhan".

Sangat penting untuk memahami mengapa kita harus repot-repot menggunakan lebih dari satu garis hubungan. Alasan yang paling jelas adalah untuk menggambarkan hubungan orangtua-anak antara kelas (ketika orangtua menghapus semua anaknya dihapus sebagai hasilnya), tetapi lebih impoten, kami ingin membedakan antara asosiasi sederhana dan komposisi untuk menempatkan pembatasan implisit pada visibilitas dan propagasi perubahan ke kelas terkait, masalah yang memainkan peran penting dalam memahami dan mengurangi kompleksitas sistem.

Asosiasi

Cara paling abstrak untuk menggambarkan hubungan statis antara kelas-kelas adalah menggunakan tautan Asosiasi, yang hanya menyatakan bahwa ada semacam tautan atau ketergantungan antara dua kelas atau lebih.

Asosiasi yang lemah

ClassA dapat ditautkan ke ClassB untuk menunjukkan bahwa salah satu metodenya mencakup parameter instance ClassB, atau mengembalikan instance ClassB.

Asosiasi yang kuat

ClassA juga dapat ditautkan ke ClassB untuk menunjukkan bahwa ia memiliki referensi ke instance ClassB.

Agregasi (Asosiasi Bersama)

Dalam kasus di mana ada bagian-hubungan antara ClassA (keseluruhan) dan ClassB (bagian), kita bisa lebih spesifik dan menggunakan tautan agregasi alih-alih tautan asosiasi, menyoroti bahwa ClassB juga dapat dikumpulkan oleh kelas-kelas lain dalam aplikasi ( karena itu agregasi juga dikenal sebagai asosiasi bersama).

Penting untuk dicatat bahwa tautan agregasi tidak menyatakan dengan cara apa pun bahwa ClassA memiliki ClassB atau bahwa ada hubungan orangtua-anak (ketika orangtua menghapus semua anaknya sedang dihapus sebagai hasilnya) di antara keduanya. Sebenarnya, justru sebaliknya! Link agregasi biasanya digunakan untuk menekankan bahwa ClassA bukan wadah eksklusif ClassB, karena sebenarnya ClassB memiliki wadah lain.

Agregasi vs Asosiasi Link asosiasi dapat menggantikan tautan agregasi di setiap situasi, sedangkan agregasi tidak dapat menggantikan asosiasi dalam situasi di mana hanya ada 'tautan lemah' antara kelas, yaitu ClassA memiliki metode yang mengandung parameter ClassB tetapi ClassA tidak tahan referensi ke instance ClassB.

Martin Fowler menyarankan bahwa tautan agregasi tidak boleh digunakan sama sekali karena tidak memiliki nilai tambah dan mengganggu konsistensi, Mengutip Jim Rumbaugh "Anggap saja sebagai plasebo pemodelan".

Komposisi (Asosiasi Tidak Dibagi)

Kita harus lebih spesifik dan menggunakan tautan komposisi dalam kasus di mana selain bagian-hubungan antara ClassA dan ClassB - ada ketergantungan siklus hidup yang kuat antara keduanya, yang berarti bahwa ketika ClassA dihapus maka ClassB juga dihapus sebagai hasilnya

Tautan komposisi menunjukkan bahwa suatu kelas (wadah, keseluruhan) memiliki kepemilikan eksklusif atas kelas lain (bagian), yang berarti bahwa objek wadah dan bagian-bagiannya merupakan hubungan orangtua-anak.

Tidak seperti asosiasi dan agregasi, ketika menggunakan hubungan komposisi, kelas yang dikomposisikan tidak dapat muncul sebagai tipe kembali atau tipe parameter dari kelas komposit. Dengan demikian, perubahan pada kelas yang dikomposisikan tidak dapat menyebar ke seluruh sistem. Akibatnya, penggunaan komposisi membatasi pertumbuhan kompleksitas ketika sistem tumbuh.

Mengukur kompleksitas sistem

Kompleksitas sistem dapat diukur hanya dengan melihat diagram kelas UML dan mengevaluasi garis hubungan asosiasi, agregasi, dan komposisi. Cara untuk mengukur kompleksitas adalah dengan menentukan berapa banyak kelas yang dapat dipengaruhi dengan mengubah kelas tertentu. Jika kelas A memperlihatkan kelas B, maka setiap kelas yang menggunakan kelas A secara teoritis dapat dipengaruhi oleh perubahan ke kelas B. Jumlah dari jumlah kelas yang berpotensi terpengaruh untuk setiap kelas dalam sistem adalah total kompleksitas sistem.

Anda dapat membaca lebih lanjut di blog saya: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

Komposisi (Jika Anda menghapus "keseluruhan", "bagian" juga dihapus secara otomatis– "Kepemilikan")

• Buat objek dari kelas Anda yang ada di dalam kelas baru. Ini disebut komposisi karena kelas baru terdiri dari objek kelas yang ada.

• Biasanya menggunakan variabel anggota normal.

• Dapat menggunakan nilai penunjuk jika kelas komposisi secara otomatis menangani alokasi / deallokasi yang bertanggung jawab atas pembuatan / penghancuran subkelas.

Komposisi dalam C ++

#include <iostream>
using namespace std;
/********************** Engine Class ******************/
class Engine
{
    int nEngineNumber;
    public:
    Engine(int nEngineNo);
    ~Engine(void);
};
Engine::Engine(int nEngineNo)
{
    cout<<" Engine :: Constructor " <<endl;
}
Engine::~Engine(void)
{
    cout<<" Engine :: Destructor " <<endl;
}
/********************** Car Class ******************/
class Car
{
    int nCarColorNumber;
    int nCarModelNumber;
    Engine objEngine;
    public:
    Car (int, int,int);
    ~Car(void);
};
Car::Car(int nModelNo,int nColorNo, int nEngineNo):
nCarModelNumber(nModelNo),nCarColorNumber(nColorNo),objEngine(nEngineNo)
{
    cout<<" Car :: Constructor " <<endl;
}
Car::~Car(void)
{
    cout<<" Car :: Destructor " <<endl;
    Car
    Engine
    Figure 1 : Composition
}
/********************** Bus Class ******************/
class Bus
{
    int nBusColorNumber;
    int nBusModelNumber;
    Engine* ptrEngine;
    public:
    Bus(int,int,int);
    ~Bus(void);
};
Bus::Bus(int nModelNo,int nColorNo, int nEngineNo):
nBusModelNumber(nModelNo),nBusColorNumber(nColorNo)
{
    ptrEngine = new Engine(nEngineNo);
    cout<<" Bus :: Constructor " <<endl;
}
Bus::~Bus(void)
{
    cout<<" Bus :: Destructor " <<endl;
    delete ptrEngine;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    // Composition using simple Engine in a car object
    {
        cout<<"------------- Inside Car Block ------------------"<<endl;
        Car objCar (1, 2,3);
    }
    cout<<"------------- Out of Car Block ------------------"<<endl;
    // Composition using pointer of Engine in a Bus object
    {
        cout<<"------------- Inside Bus Block ------------------"<<endl;
        Bus objBus(11, 22,33);
    }
    cout<<"------------- Out of Bus Block ------------------"<<endl;
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Keluaran

--------------- Start Of Program --------------------
------------- Inside Car Block ------------------
Engine :: Constructor
Car :: Constructor
Car :: Destructor
Engine :: Destructor
------------- Out of Car Block ------------------
------------- Inside Bus Block ------------------
Engine :: Constructor
Bus :: Constructor
Bus :: Destructor
Engine :: Destructor
------------- Out of Bus Block ------------------
--------------- End Of Program --------------------

Agregasi (Jika Anda menghapus "keseluruhan", "Bagian" dapat ada - "Tanpa Kepemilikan")

• Agregasi adalah jenis komposisi tertentu di mana tidak ada kepemilikan antara objek kompleks dan sub-objek tersirat. Ketika agregat dihancurkan, sub-objek tidak dihancurkan.

• Biasanya menggunakan variabel pointer / variabel referensi yang menunjuk ke objek yang hidup di luar lingkup kelas agregat

• Dapat menggunakan nilai referensi yang menunjuk ke objek yang hidup di luar lingkup kelas agregat

• Tidak bertanggung jawab untuk membuat / menghancurkan subclass

Kode Agregasi dalam C ++

#include <iostream>
#include <string>
using namespace std;
/********************** Teacher Class ******************/
class Teacher
{
    private:
    string m_strName;
    public:
    Teacher(string strName);
    ~Teacher(void);
    string GetName();
};
Teacher::Teacher(string strName) : m_strName(strName)
{
    cout<<" Teacher :: Constructor --- Teacher Name :: "<<m_strName<<endl;
}
Teacher::~Teacher(void)
{
    cout<<" Teacher :: Destructor --- Teacher Name :: "<<m_strName<<endl;
}
string Teacher::GetName()
{
    return m_strName;
}
/********************** Department Class ******************/
class Department
{
    private:
    Teacher *m_pcTeacher;
    Teacher& m_refTeacher;
    public:
    Department(Teacher *pcTeacher, Teacher& objTeacher);
    ~Department(void);
};
Department::Department(Teacher *pcTeacher, Teacher& objTeacher)
: m_pcTeacher(pcTeacher), m_refTeacher(objTeacher)
{
    cout<<" Department :: Constructor " <<endl;
}
Department::~Department(void)
{
    cout<<" Department :: Destructor " <<endl;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    {
        // Create a teacher outside the scope of the Department
        Teacher objTeacher("Reference Teacher");
        Teacher *pTeacher = new Teacher("Pointer Teacher"); // create a teacher
        {
            cout<<"------------- Inside Block ------------------"<<endl;
            // Create a department and use the constructor parameter to pass the teacher to it.
            Department cDept(pTeacher,objTeacher);
            Department
            Teacher
            Figure 2: Aggregation
        } // cDept goes out of scope here and is destroyed
        cout<<"------------- Out of Block ------------------"<<endl;
        // pTeacher still exists here because cDept did not destroy it
        delete pTeacher;
    }
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Keluaran

--------------- Start Of Program --------------------
Teacher :: Constructor --- Teacher Name :: Reference Teacher
Teacher :: Constructor --- Teacher Name :: Pointer Teacher
------------- Inside Block ------------------
Department :: Constructor
Department :: Destructor
------------- Out of Block ------------------
Teacher :: Destructor --- Teacher Name :: Pointer Teacher
Teacher :: Destructor --- Teacher Name :: Reference Teacher
--------------- End Of Program --------------------

Masalah dengan jawaban-jawaban ini adalah mereka setengah dari cerita: mereka menjelaskan bahwa agregasi dan komposisi adalah bentuk-bentuk asosiasi, tetapi mereka tidak mengatakan apakah mungkin sebuah asosiasi bukan keduanya.

Saya mengumpulkan berdasarkan beberapa pembacaan singkat dari banyak posting di SO dan beberapa dokumen UML bahwa ada 4 bentuk konkret utama dari asosiasi kelas:

1. komposisi: A-terdiri-dari-B; B tidak ada tanpa A, seperti kamar di rumah
2. agregasi: A memiliki-a B; B bisa ada tanpa A, seperti siswa di kelas
3. ketergantungan: A menggunakan-a B; tidak ada ketergantungan siklus hidup antara A dan B, seperti parameter pemanggilan metode, nilai balik, atau sementara yang dibuat selama pemanggilan metode
4. generalisasi: A is-a B

Ketika hubungan antara dua entitas bukan salah satu dari ini, itu hanya bisa disebut "asosiasi" dalam arti umum dari istilah tersebut, dan selanjutnya dijelaskan cara lain (catatan, stereotip, dll).

Dugaan saya adalah bahwa "asosiasi generik" dimaksudkan untuk digunakan terutama dalam dua keadaan:

• ketika kekhasan suatu hubungan sedang dikerjakan; hubungan seperti itu dalam diagram harus dikonversi sesegera mungkin menjadi apa yang sebenarnya / akan (salah satu dari 4 lainnya)
• ketika suatu hubungan tidak cocok dengan 4 dari yang telah ditentukan oleh UML; asosiasi "generik" masih memberi Anda cara mewakili hubungan yang "bukan salah satu dari yang lain", sehingga Anda tidak terjebak menggunakan hubungan yang salah dengan catatan "ini sebenarnya bukan agregasi, hanya saja UML tidak memiliki simbol lain yang bisa kita gunakan "

Saya pikir tautan ini akan melakukan pekerjaan rumah Anda: http://ootips.org/uml-hasa.html

Untuk memahami istilah yang saya ingat contoh di hari-hari awal pemrograman saya:

Jika Anda memiliki objek 'papan catur' yang berisi objek 'kotak' yang merupakan komposisi karena jika 'papan catur' dihapus, tidak ada alasan untuk kotak-kotak itu ada lagi.

Jika Anda memiliki objek 'kotak' yang memiliki objek 'warna' dan kotak akan dihapus objek 'warna' mungkin masih ada, yaitu agregasi

Keduanya adalah asosiasi , perbedaan utamanya adalah konseptual

Komposisi : Ini adalah di mana begitu Anda menghancurkan benda (Sekolah), benda lain (Ruang Kelas) yang terikat dengannya akan hancur juga. Keduanya tidak bisa eksis secara mandiri.

Agregasi : Ini adalah kebalikan dari Compositionasosiasi di atas ( ) di mana begitu Anda membunuh objek ( Company), objek lain ( Employees) yang terikat padanya dapat ada dengan sendirinya.

Asosiasi .
Komposisi dan Agregasi adalah dua bentuk asosiasi.

    Simple rules:
    A "owns" B = Composition : B has no meaning or purpose in the system 
    without A
    A "uses" B = Aggregation : B exists independently (conceptually) from A
    A "belongs/Have" B= Association; And B exists just have a relation
    Example 1:

    A Company is an aggregation of Employees.
    A Company is a composition of Accounts. When a Company ceases to do 
    business its Accounts cease to exist but its People continue to exist. 
    Employees have association relationship with each other.

    Example 2: (very simplified)
    A Text Editor owns a Buffer (composition). A Text Editor uses a File 
    (aggregation). When the Text Editor is closed,
    the Buffer is destroyed but the File itself is not destroyed.

Dalam kalimat yang sangat sederhana:
Agregasi dan Komposisi adalah himpunan bagian dari asosiasi.

• A menggunakan B -> ini adalah agregasi

• Kebutuhan B -> adalah komposisi.

Baca lebih lanjut di sini .

Saya ingin menggambarkan bagaimana ketiga istilah ini diterapkan dalam Rails. ActiveRecord memanggil segala jenis hubungan antara dua model an association. Seseorang tidak akan menemukan istilah yang sangat sering compositiondan aggregation, ketika membaca dokumentasi atau artikel, terkait dengan ActiveRecord. Asosiasi dibuat dengan menambahkan salah satu makro kelas asosiasi ke tubuh kelas. Beberapa macro ini belongs_to, has_one,has_many dll ..

Jika kita ingin mengatur a compositionatau aggregation, kita perlu menambahkan belongs_toke model yang dimiliki (juga disebut child) dan has_oneatau has_manyke model yang dimiliki (juga disebut induk). Apakah kita mengatur compositionatau aggregationtergantung pada opsi yang kita berikan untuk belongs_topanggilan dalam model anak. Sebelum Rails 5, pengaturan belongs_totanpa opsi apa pun yang dibuat aggregation, anak bisa ada tanpa orangtua. Jika kami menginginkan composition, kami perlu menyatakan ini secara eksplisit dengan menambahkan opsi required: true:

class Room < ActiveRecord::Base
  belongs_to :house, required: true
end

Di Rails 5 ini diubah. Sekarang, mendeklarasikan belongs_toasosiasi membuat secara compositiondefault, anak tidak dapat ada tanpa orangtua. Jadi contoh di atas dapat ditulis ulang sebagai:

class Room < ApplicationRecord
  belongs_to :house
end

Jika kita ingin membiarkan objek anak ada tanpa orangtua, kita perlu mendeklarasikan ini secara eksplisit melalui opsi optional

class Product < ApplicationRecord
  belongs_to :category, optional: true
end

Dari: Remo H. Jansen buku "Beginning React: Learning TypeScript 2.x - Edisi Kedua":

Kami menyebutnya asosiasi itu hubungan yang objeknya memiliki siklus hidup mandiri di mana tidak ada kepemilikan objek. Mari kita lihat contoh guru dan siswa. Banyak siswa dapat dikaitkan dengan satu guru, dan satu siswa dapat dikaitkan dengan banyak guru, tetapi keduanya memiliki siklus hidup mandiri (keduanya dapat membuat dan menghapus secara mandiri). Jadi, ketika seorang guru meninggalkan sekolah, kita tidak perlu menghapus siswa, dan ketika seorang siswa meninggalkan sekolah, kita tidak perlu menghapus guru mana pun.

Kami menyebut agregasi hubungan-hubungan yang objek-objeknya memiliki siklus hidup yang independen, tetapi ada kepemilikan, dan objek anak tidak dapat dimiliki oleh objek induk lainnya. Mari kita ambil contoh ponsel dan baterai ponsel. Baterai tunggal dapat menjadi milik telepon, tetapi jika telepon berhenti berfungsi, dan kami menghapusnya dari basis data kami, baterai telepon tidak akan dihapus karena mungkin masih berfungsi. Jadi, secara agregat, sementara ada kepemilikan, objek memiliki siklus hidupnya

Kami menggunakan istilah komposisi untuk merujuk ke hubungan yang objeknya tidak memiliki siklus hidup independen, dan jika objek induk dihapus, semua objek anak juga akan dihapus. Mari kita ambil contoh hubungan antara pertanyaan dan jawaban. Pertanyaan tunggal dapat memiliki beberapa jawaban, dan jawaban tidak dapat dimiliki oleh beberapa pertanyaan. Jika kami menghapus pertanyaan, jawaban akan dihapus secara otomatis.

Asosiasi adalah hubungan antara dua kelas yang terpisah dan asosiasi dapat dari jenis apa saja, dari satu ke satu, satu ke yang lain, dll. Ia bergabung dengan dua entitas yang sepenuhnya terpisah.

Agregasi adalah bentuk asosiasi khusus yang merupakan hubungan satu arah searah antara kelas (atau entitas), misalnya untuk kelas Dompet dan Uang. Dompet memiliki Uang tetapi uang tidak perlu memiliki Dompet, jadi itu adalah hubungan satu arah. Dalam hubungan ini kedua entri dapat bertahan jika yang lain berakhir. Dalam contoh kami jika kelas Wallet tidak ada, itu tidak berarti bahwa kelas Uang tidak ada.

Komposisi adalah bentuk Agregasi terbatas di mana dua entitas (atau bisa dikatakan kelas) sangat bergantung satu sama lain. Misalnya untuk Manusia dan Jantung. Manusia membutuhkan hati untuk hidup dan hati membutuhkan tubuh manusia untuk bertahan hidup. Dengan kata lain ketika kelas (entitas) saling bergantung dan masa hidup mereka sama (jika satu mati maka yang lain juga) maka komposisi. Kelas jantung tidak masuk akal jika kelas Manusia tidak ada.

https://www.linkedin.com/pulse/types-relationships-object-oriented-programming-oop-sarah-el-dawody/

Komposisi: adalah hubungan "bagian dari".

misalnya "mesin adalah bagian dari mobil", "jantung adalah bagian dari tubuh".

Asosiasi: adalah tipe hubungan “has-a”

Sebagai contoh, misalkan kita memiliki dua kelas maka dua kelas ini dikatakan sebagai hubungan “memiliki-a” jika kedua entitas ini berbagi objek satu sama lain untuk beberapa pekerjaan dan pada saat yang sama mereka dapat hidup tanpa ketergantungan satu sama lain atau keduanya memiliki seumur hidup sendiri.

Contoh di atas menunjukkan hubungan asosiasi karena kelas Karyawan dan Manajer menggunakan objek satu sama lain dan keduanya siklus hidup mandiri mereka sendiri.

Agregasi: didasarkan pada hubungan "has-a" dan itu adalah bentuk asosiasi khusus

misalnya, "Siswa" dan "alamat". Setiap siswa harus memiliki alamat sehingga hubungan antara kelas Siswa dan kelas Alamat akan menjadi tipe hubungan “Has-A” tetapi sebaliknya tidak benar.