İlişkilendirme, toplama ve kompozisyon arasındaki fark nedir?

İlişkilendirme, toplama ve kompozisyon arasındaki fark nedir? Lütfen uygulama açısından açıklayınız.

İki nesne için Foove Barilişkiler tanımlanabilir

İlişki - Bir nesne ile ilişkim var. FookullanımlarıBar

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

Kompozisyon - Bir nesnem var ve ömründen ben sorumluyum. Öldüğünde de FooöyleBar

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

Toplama - Başka birinden ödünç aldığım bir nesnem var. Ne zaman Fooölür, Barüzerinde yaşayabilir.

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

Bu sorunun C # olarak etiketlendiğini biliyorum, ancak kavramlar burada bu yönlendirme gibi oldukça genel sorular . Bu yüzden benim bakış açımı burada sunacağım (biraz daha rahat olduğum için java açısından önyargılı).

Nesne yönelimli doğayı düşündüğümüzde daima Nesneleri, sınıfı (nesne planları) ve aralarındaki ilişkiyi düşünürüz. Nesneler birbiriyle ilişkilidir ve yöntemlerle birbirleriyle etkileşime girer. Başka bir deyişle, bir sınıfın nesnesi başka bir sınıfın nesnesi tarafından sağlanan hizmetleri / yöntemleri kullanabilir. Bu tür bir ilişki dernek olarak adlandırılır . .

Toplama ve Kompozisyon, ilişkilendirmenin alt kümeleridir, yani belirli ilişkilendirme durumlarıdır.

• Bir sınıfın hem toplama hem de kompozisyon nesnesinde başka bir sınıfın nesnesi "sahibi" olur .
• Ancak ince bir fark var. Gelen Kompozisyon bunun nesnenin aittir sınıfın nesne sınıfını sahip oluyor Üzerinde canlı olarak değil kendi var (Ayrıca denilen "ölüm ilişkisi"). Öyle olacak gibi 's sahibi nesnenin bir parçası olarak her zaman canlı Aggregation bağımlı nesnedir bağımsız ve sınıfı sahip olma amacı, ölü olsa bile bulunabilir.
• Yani kompozisyonda sahip olunan nesne çöp toplanırsa, sahip olunan nesne de toplamada böyle olmaz.

Şaşkın?

Kompozisyon Örneği : Bir araba ve o arabaya çok özgü bir motor örneğini düşünün (başka bir arabada kullanılamaz). Car ve SpecificEngine sınıfı arasındaki bu tür ilişkiye Kompozisyon denir. Car sınıfının bir nesnesi, SpecificEngine sınıfının bir nesnesi olmadan var olamaz ve SpecificEngine nesnesinin Car sınıfı olmadan bir önemi yoktur. Basitçe söylemek gerekirse Araba sınıfı sadece SpecificEngine sınıfına "sahiptir".

Toplama Örnek : Şimdi Car ve class Wheel sınıflarını düşünün . Aracın çalışması için bir Tekerlek nesnesine ihtiyacı var. Car nesnesinin Wheel nesnesinin sahibi olduğu anlamına gelir, ancak Wheel nesnesinin Car Nesnesi olmadan hiçbir önemi olmadığını söyleyemeyiz. Bisiklet, Kamyon veya farklı Otomobil Nesnelerinde çok iyi kullanılabilir.

Özetle -

Özetlemek gerekirse ilişkilendirme, bir sınıf başka bir sınıf tarafından sağlanan işlevleri kullandığında temsil etmek için kullanılan çok genel bir terimdir. Bir üst sınıf nesnesinin başka bir alt sınıf nesnesine sahip olması ve bu alt sınıf nesnesinin üst sınıf nesnesi olmadan anlamlı bir şekilde var olamamasının kompozisyon olduğunu söylüyoruz. Eğer yapabilirse buna Toplama denir.

Daha fazla ayrıntı burada. Ben http://opensourceforgeeks.blogspot.in yazarım ve daha fazla bağlam için yukarıdaki ilgili bağlantıya bir bağlantı ekledim.

Dernek genelleştirilmiş ilişkiler kavramıdır. Hem Kompozisyon hem de Toplama içerir.

Kompozisyon ( karışım ), basit nesneleri veya veri türlerini tek bir birime sarmanın bir yoludur . Kompozisyonlar, birçok temel veri yapısının kritik bir yapı taşıdır

Toplama ( toplama ), sahiplik anlamına gelmediği için sıradan kompozisyondan farklıdır. Kompozisyonda, sahip olan nesne yok edildiğinde, içerilen nesneler de yok olur. Toplamada, bu her zaman doğru değildir.

Her ikisi de nesne arasındaki ilişkiyi gösterir ve sadece güçlerinde farklılık gösterir.

Farkı hatırlama hilesi: A - A grubu ve O wn - c O mpositoin var

Şimdi aşağıdaki görüntüyü gözlemleyelim

Analoji:

Kompozisyon : Aşağıdaki resim, bir resim oluşturan münferit görüntüleri kullanan görüntü kompozisyonudur.

Toplama : görüntünün tek bir konumda toplanması

Örneğin, bir üniversitenin çeşitli bölümleri vardır ve her bölümün çeşitli profesörleri vardır. Üniversite kapanırsa, bölümler artık mevcut olmayacak, ancak bu bölümlerdeki profesörler var olmaya devam edecektir. Bu nedenle, bir üniversite bölümlerin bir bileşimi olarak görülebilirken, bölümlerin bir profesör topluluğu vardır. Buna ek olarak, bir Profesör birden fazla bölümde çalışabilir, ancak bir bölüm birden fazla üniversitenin parçası olamaz.

Bağımlılık (referanslar)
İki nesne arasında kavramsal bir bağlantı olmadığı anlamına gelir. Örneğin EnrollmentService nesnesi Öğrenci ve Ders nesnelerine başvurur (yöntem parametreleri veya dönüş türleri olarak)

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

İlişki (has-a)
Bu, nesneler arasında neredeyse her zaman bir bağlantı olduğu anlamına gelir (ilişkilendirilir). Sipariş nesnesinin bir Müşteri nesnesi var

public class Order {
    private Customer customer
}

Toplama (tüm-a + tüm-parçası vardır)
İki nesne arasında tam-parça ilişkisinin olduğu özel tür bir ilişki. yine de birbirleri olmadan yaşayabilirler.

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

Not: En zor kısım, kümelemeyi normal ilişkiden ayırmaktır. Dürüst olmak gerekirse, bunun farklı yorumlara açık olduğunu düşünüyorum.

Kompozisyon (has-a + tüm bölüm + sahiplik)
Özel tür toplama. An Apartmentbazı Rooms'den oluşur . A Room, bir olmadan var olamaz Apartment. bir daire silindiğinde, ilişkili tüm odalar da silinir.

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

Bir yayından comp.object Robert Martin :

İlişkilendirme, bir örneğin başka bir örneğe ileti gönderme yeteneğini temsil eder. Bu, bir yöntem bağımsız değişkeni veya yerel bir değişkenin oluşturulması olarak da uygulanabilmesine rağmen, genellikle bir işaretçi veya başvuru örneği değişkeni ile uygulanır.

//[Example:]

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

class A
{
  private:
    B* itsB;
};

Toplama [...] tipik bir tam / parça ilişkisidir. Bu, örneklerin döngüsel toplama ilişkilerine sahip olamaması (yani bir bölüm bütününü içeremez) istisnası ile tam olarak aynıdır.

//[Example:]

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

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

Bunun kümelenme olması, Düğüm örneklerinin bir döngü oluşturamayacağı anlamına gelir. Bu nedenle, bu bir Düğümler Ağacı değildir.

Kompozisyon [...], “parçanın” kullanım ömrünün “bütün” tarafından kontrol edilmesi dışında Toplama gibidir. Bu kontrol doğrudan veya geçişli olabilir. Yani, "bütün", "parçayı" oluşturmak veya imha etmek için doğrudan sorumluluk alabilir veya önceden oluşturulmuş bir parçayı kabul edebilir ve daha sonra onu sorumluluk üstlenen başka bir bütüne aktarabilir.

//[Example:]

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

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

Diğerlerinin söylediği gibi, bir ilişki nesneler arasındaki bir ilişkidir, toplama ve kompozisyon birleşme türüdür.

Uygulama açısından bakıldığında, bir sınıf üyesine başvurularak bir toplama elde edilir . Örneğin, A sınıfı B sınıfı bir nesneyi toplarsa, böyle bir şeye sahip olursunuz (C ++ ile):

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

Toplama anlambilimi, A nesnesi yok edildiğinde, depoladığı B nesnesinin hala var olacağıdır. Kompozisyonu kullanırken, genellikle üyeyi değere göre depolayarak daha güçlü bir ilişkiniz vardır :

class A {
    B element;
};

Burada, bir A nesnesi yok edildiğinde, içerdiği B nesnesi de yok edilir. Bunu yapmanın en kolay yolu, üyeyi değere göre depolamaktır, ancak akıllı bir işaretçi de kullanabilir veya üyeyi yıkıcıda silebilirsiniz:

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

class A {
    B * element;

    ~A() {
        delete B;
    }
};

Önemli olan, bir kompozisyonda, konteyner nesnesinin içerdiği nesneye sahip olması, oysa toplamada buna gönderme yapmasıdır.

Üç ilişki kavramı birliği , kümelenme ve kompozisyon arasındaki ayrım konusunda ne kadar karışıklık olduğu şaşırtıcı .

Toplama ve kompozisyon terimlerinin C ++ topluluğunda, muhtemelen UML Sınıf Diyagramlarında özel ilişkilendirme vakaları olarak tanımlanmadan önce kullanıldığına dikkat edin .

Asıl sorun, kompozisyon kavramının, bütün ve parçaları arasında bir yaşam döngüsü bağımlılığı anlamına geldiği, parçaların bütünü olmadan var olamayacağı, yaygın olarak göz ardı edildiği, yaygın ve devam eden yanlış anlamadır (uzman yazılım geliştiricileri arasında bile). parçaların bütünden ayrılabildiği ve imhadan kurtulabildiği paylaşılamayan parçalarla parça-bütün ilişkilendirme vakaları.

Görebildiğim kadarıyla, bu karışıklığın iki kökü var:

1. C ++ topluluğunda, "toplama" terimi , UML Sınıf Diyagramlarında birleşme duygusu olan başka bir bağımsız sınıfın nesnelerine referans vermek için bir özniteliği tanımlayan bir sınıf anlamında kullanılmıştır (bakınız örneğin [1]) . "Kompozisyon" terimi, nesneleri için bileşen nesneleri tanımlayan sınıflar için kullanıldı, böylece bileşik nesnenin imhası üzerine, bu bileşen nesneleri de yok edildi.

2. UML Sınıf Diyagramlarında, hem "kümelenme" hem de "kompozisyon", kısmi bütün ilişkileri temsil eden (uzun süredir felsefede tartışılan) özel ilişkilendirme vakaları olarak tanımlanmıştır . Tanımlarında, bir "toplama" ve "kompozisyon" arasındaki ayrım, bir parçanın iki veya daha fazla wholes arasında paylaşılmasına izin verip vermediğine dayanır. "Kompozisyonları", paylaşılamayan (münhasır) parçalara sahip olarak tanımlarken, "toplamalar" parçalarını paylaşabilir. Ek olarak, aşağıdakine benzer bir şey söylerler: çoğu zaman, ancak her durumda değil, kompozisyonlar, parçaların bütünü olmadan var olamayacağı şekilde bütün ve parçaları arasında bir yaşam döngüsü bağımlılığı ile gelir.

Bu nedenle, UML "toplama" ve "kompozisyon" terimlerini doğru kısma (kısmen-bütün ilişkilerin) koymuş olsa da, bunları geliştiricilerin sezgilerini yakalayarak açık ve net bir şekilde tanımlamayı başaramamıştır. Bununla birlikte, bu şaşırtıcı değildir, çünkü bu ilişkilerin sahip olabileceği çok farklı özellikler (ve uygulama nüansları) vardır ve geliştiriciler bunları nasıl uygulayacakları konusunda anlaşmazlar.

Ayrıca , aşağıda listelenen Nisan 2009'daki SO sorusuna verilen genişletilmiş yanıma da bakın.

Ve C ++ topluluğundaki OOP nesneleri arasında "kompozisyon" tanımladığı kabul edilen özellik (ve bu inanç hala geniş ölçüde tutulmaktadır): iki ilişkili nesne (kompozit ve bileşeni) arasındaki çalışma zamanı yaşam döngüsü bağımlılığı, "kompozisyon" için gerçekten karakteristik değildir, çünkü diğer ilişkilendirme türlerinde de referans bütünlüğünden dolayı bu tür bağımlılıklara sahip olabiliriz.

Örneğin, bir SO cevabında "kompozisyon" için aşağıdaki kod modeli önerilmiştir :

final class Car {    
  private final Engine engine;

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

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

Katılımcı, başka hiçbir sınıfın bileşene referansta bulunamayacağını / tanıyamayacağını "kompozisyon" için karakteristik olacağını iddia etmiştir. Ancak, bu tüm olası "kompozisyon" vakaları için kesinlikle doğru değildir. Özellikle, bir arabanın motoru söz konusu olduğunda, muhtemelen başka bir sınıfın yardımıyla uygulanan arabanın üreticisi, bir sorun olduğunda aracın sahibiyle iletişim kurabilmesi için motora başvurmak zorunda kalabilir.

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

Ek - StackOverflow'daki kompozisyon ve toplama hakkında tekrar tekrar sorulan soruların eksik listesi

[ Nis 2009 ]
Kompozisyona Karşı Kompozisyon [öncelikle görüşe dayalı olarak kapatıldı]
[ Nis 2009 ]
Kompozisyon ve Birlik ilişkisi arasındaki fark nedir?
[ Mayıs 2009 ]
Dernek, kümeleme ve kompozisyon arasındaki fark
[ Mayıs 2009 ]
Kompozisyon ve toplama arasındaki fark nedir? [duplicate]
[ Eki 2009 ]
Toplama, kompozisyon ve bağımlılık arasındaki fark nedir? [yinelenen olarak işaretlendi]
[ Kas 2010 ]
İlişkilendirme ile Toplama [yinelenen olarak işaretlendi]
[Ağu 2012 ]
Java'da Toplama ve Kompozisyon arasındaki uygulama farkı
[ Şub 2015 ]
UML - ilişkilendirme veya toplama (basit kod snippet'leri)

bağlantı

İlişkilendirme iki sınıf arasındaki ilişkiyi temsil eder. Tek yönlü (tek yönlü) veya çift yönlü (iki yönlü) olabilir

Örneğin:

1. tek yönlü

Müşteri sipariş verir

2. İki yönlü

A, B ile evli

B, A ile evli

toplanma

Toplama bir tür ilişkilendirmedir.Ama belirli özelliklere sahiptir.Ayrıca, daha büyük bir "bütün" sınıftaki ilişki, bir veya daha fazla "parça" sınıfı içerir. Buna karşılık, daha küçük bir "parça" sınıfı, "bütün" daha büyük sınıfın bir parçasıdır .

Örneğin:

kulübün üyeleri var

Bir kulüp ("bütün") birkaç kulüp üyesinden ("bölümler") oluşur. Kulüp ("bütün") ölecek olsaydı, üyeler ("parçalar") onunla ölmezdi. Çünkü üye birden fazla kulübe ait olabilir ("bütün").

Kompozisyon

Bu daha güçlü bir toplama biçimidir. "Bütün", "parçalarının" yaratılmasından veya yok edilmesinden sorumludur.

Örneğin:

Bir okulun bölümleri vardır

Bu durumda okul ("bütün") ölecekti, bölüm ("parçalar") onunla birlikte ölecekti. Çünkü her bölüm sadece bir "bütün" e ait olabilir.

Neden birden fazla ilişki çizgisi kullanmaktan rahatsız olmamız gerektiğini anlamak önemlidir. En belirgin neden, sınıflar arasındaki ebeveyn-çocuk ilişkisini tanımlamaktır (ebeveyn, tüm çocuğunu sildiğinde sonuç olarak silinir), ancak daha iktidarsız olarak, görünürlük üzerine örtülü kısıtlamalar koymak ve değişikliklerin ilgili sınıflara yayılması, sistem karmaşıklığının anlaşılmasında ve azaltılmasında önemli rol oynayan bir konudur .

bağlantı

Sınıflar arasındaki statik ilişkiyi tanımlamanın en soyut yolu, iki sınıf veya daha fazlası arasında bir tür bağlantının veya bağımlılığın olduğunu belirten Association bağlantısını kullanmaktır.

Zayıf Dernek

ClassA, yöntemlerinden birinin ClassB örneğinin parametresini veya ClassB örneğinin döndürdüğünü göstermek için ClassB'ye bağlanabilir.

Güçlü Birlik

ClassA, ClassB örneğine bir başvuruda bulunduğunu göstermek için ClassB'ye de bağlanabilir.

Toplama (Paylaşılan Dernek)

ClassA (bütün) ve ClassB (bölüm) arasında bir ilişkinin bir parçası olduğu durumlarda, daha spesifik olabilir ve ilişkilendirme bağlantısı yerine toplama bağlantısını kullanabiliriz, ClassB'nin uygulamadaki diğer sınıflar tarafından da toplanabileceğini vurgulayabiliriz ( bu nedenle toplama aynı zamanda paylaşılan ilişkilendirme olarak da bilinir).

Toplama bağlantısının ClassA'nın ClassB'ye sahip olduğunu veya ikisi arasında bir ebeveyn-çocuk ilişkisi (ebeveyn silindiğinde tüm çocuğunun silinmesi durumunda) olduğunu hiçbir şekilde belirtmediğini belirtmek önemlidir. Aslında, tam tersi! Toplama bağlantısı genellikle ClassA'nın ClassB'nin münhasır kabı olmadığı noktasını vurgulamak için kullanılır, çünkü aslında ClassB'nin başka bir kabı vardır.

Toplama ve İlişkilendirme İlişkilendirme bağlantısı her durumda toplama bağlantısının yerini alabilirken, toplama işlemi sınıflar arasında yalnızca 'zayıf bir bağ' olduğu durumlarda ilişkilendirmenin yerini alamaz; yani ClassA, ClassB parametresini içeren yöntemlere sahiptir, ancak ClassA ClassB örneğine başvuru tutun.

Martin Fowler, toplama bağlantısının hiçbir katma değeri olmadığı ve tutarlılığı bozduğu için kullanılmaması gerektiğini öne sürüyor, Jim Rumbaugh'dan alıntı yap "Bunu bir modelleme plasebo olarak düşün".

Kompozisyon (Paylaşılmayan Dernek)

ClassA ve ClassB arasındaki ilişkinin bir kısmına ek olarak - ikisi arasında güçlü bir yaşam döngüsü bağımlılığı olduğu durumlarda daha spesifik olmalı ve kompozisyon bağlantısını kullanmalıyız, yani ClassA silindiğinde ClassB'nin de sonuç olarak silinmesi

Kompozisyon bağlantısı, bir sınıfın (konteynır, bütün) diğer sınıf (lar) üzerinde münhasır sahipliğe sahip olduğunu gösterir, yani konteynır nesnesi ve bölümlerinin bir üst-alt-çocuk ilişkisi oluşturduğu anlamına gelir.

İlişkilendirme ve toplama işleminin aksine, kompozisyon ilişkisini kullanırken, oluşturulan sınıf kompozit sınıfın bir dönüş türü veya parametre türü olarak görünemez. Böylece, oluşturulan sınıftaki değişiklikler sistemin geri kalanına yayılamaz. Sonuç olarak, bileşimin kullanımı sistem büyüdükçe karmaşıklığın büyümesini sınırlar.

Sistem karmaşıklığını ölçme

Sistem karmaşıklığı, basitçe bir UML sınıf diyagramına bakarak ve ilişkilendirme, toplama ve kompozisyon ilişki çizgilerini değerlendirerek ölçülebilir. Karmaşıklığı ölçmenin yolu, belirli bir sınıfı değiştirerek kaç sınıfın etkilenebileceğini belirlemektir. A sınıfı B sınıfı ortaya koyarsa, A sınıfı kullanan herhangi bir sınıf teorik olarak B sınıfındaki değişikliklerden etkilenebilir. Sistemdeki her sınıf için potansiyel olarak etkilenen sınıfların toplamı toplam sistem karmaşıklığıdır.

Blogumda daha fazla bilgi bulabilirsiniz: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

Kompozisyon ("bütün" ü kaldırırsanız, "parça" da otomatik olarak kaldırılır - "Sahiplik")

• Yeni sınıfın içinde mevcut sınıfınızın nesnelerini oluşturun. Buna kompozisyon denir, çünkü yeni sınıf mevcut sınıfların nesnelerinden oluşur.

• Genellikle normal üye değişkenleri kullanın.

• Eğer kompozisyon sınıfı, alt sınıfların yaratılması / imha edilmesinden sorumlu tahsis / dağıtmayı otomatik olarak ele alıyorsa işaretçi değerlerini kullanabilir.

C ++ ile kompozisyon

#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);
}

Çıktı

--------------- 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 --------------------

Toplama ("Bütün" ifadesini kaldırırsanız, "Bölüm" mevcut olabilir - "Sahip Olmama")

• Toplama, karmaşık nesne ile alt nesneler arasında hiçbir mülkiyetin ima edilmediği belirli bir kompozisyon türüdür. Bir küme yok edildiğinde, alt nesneler yok edilmez.

• Genellikle, toplu sınıfın kapsamı dışında kalan bir nesneye işaret eden işaretçi değişkenlerini / başvuru değişkenini kullanın

• Toplama sınıfının kapsamı dışında kalan bir nesneye işaret eden referans değerleri kullanabilir

• Alt sınıf oluşturma / yok etmekten sorumlu değildir

C ++ 'da Toplama Kodu

#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);
}

Çıktı

--------------- 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 --------------------

Bu cevaplarla ilgili sorun, hikayenin yarısıdır: toplama ve kompozisyonun bir birliktelik şekli olduğunu açıklarlar, ancak bir derneğin bunlardan hiçbiri olmasının mümkün olup olmadığını söylemezler.

SO'daki birçok yazının bazı kısa okumalarına ve sınıf temel birliğinin 4 ana somut formunun bulunduğu bazı UML belgelerine dayanarak toplanıyorum:

1. kompozisyon: A, bir B'den oluşur; B evsiz bir oda gibi A olmadan var olmaz
2. kümeleşme: A has-a B; B sınıfsız bir öğrenci gibi A olmadan var olabilir
3. bağımlılık: A kullanımları-a B; yöntem çağrısı parametresi, dönüş değeri veya yöntem çağrısı sırasında oluşturulan geçici gibi A ve B arasında yaşam döngüsü bağımlılığı yok
4. genelleme: A is-a B

İki varlık arasındaki ilişki bunlardan biri değilse, bu terimin genel anlamında "ilişkilendirme" olarak adlandırılabilir ve başka şekillerde de açıklanabilir (not, basmakalıp, vb.).

Benim tahminim "jenerik dernek" öncelikle iki durumda kullanılmak üzere tasarlanmıştır:

• bir ilişkinin ayrıntıları hala üzerinde çalışırken; bir diyagramdaki bu ilişki en kısa zamanda gerçekte ne olacağına (diğerinden biri) dönüştürülmelidir.
• bir ilişki UML tarafından önceden belirlenmiş 4 taneyle eşleşmediğinde; "jenerik" dernek hala "diğerinden biri" olmayan bir ilişkiyi temsil etmenin bir yolunu sunar, böylece bir notla yanlış bir ilişki kullanarak sıkışıp kalmazsınız "bu aslında birleştirme değildir, sadece bu UML kullanabileceğimiz başka bir sembol yok "

Bu bağlantının ödevinizi yapacağını düşünüyorum: http://ootips.org/uml-hasa.html

İlk programlama günlerimdeki bir örneği hatırladığım terimleri anlamak için:

Kompozisyon olan 'kutu' nesneleri içeren bir 'satranç tahtası' nesneniz varsa, 'satranç tahtası' silinirse artık kutuların var olması için bir neden yoktur.

'Color' nesnesi olan bir 'square' nesneniz varsa ve square silinirse 'color' nesnesi hala var olabilir, yani toplama

Her ikisi de dernekler , ana fark kavramsal

Kompozisyon : Burası bir nesneyi (Okulu) yok ettiğinizde, ona bağlı olan başka bir nesneyi (Sınıflar) da yok eder. İkisi de bağımsız olarak var olamazlar.

Toplama : Bu, Compositionbir nesneyi ( Company) öldürdüğünüzde , Employeesona bağlı olan diğer nesnenin ( ) kendi başına var olabileceği yukarıdaki ( ) ilişkisinin tam tersidir .

Derneği .
Kompozisyon ve Toplama iki ilişkilendirme şeklidir.

    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.

Çok basit bir cümleyle:
Toplama ve Kompozisyon birliğin alt kümeleridir.

• A kullanır B -> bu bir toplama

• İhtiyaç olan B -> bileşimdir.

Daha fazlasını buradan okuyun .

Üç terimin Rails'te nasıl uygulandığını göstermek istiyorum. ActiveRecord iki model arasındaki her türlü ilişkiyi çağırır association. ActiveRecord ile ilgili terimler compositionve aggregationdokümanları veya makaleleri okurken çok sık bulunmaz . Bir ilişkilendirme, sınıf gövdesine ilişkilendirme sınıfı makrolarından biri eklenerek oluşturulur. Bu makroların bazıları belongs_to, has_one,has_many vb ..

Bir compositionveya ayarlamak istiyorsak , sahip olunan modele (çocuk olarak da bilinir) ve veya sahip olan modele (ebeveyn olarak da adlandırılır) aggregationeklememiz gerekir . Alt modelde aramaya geçirdiğimiz veya ayarladığımız seçeneklere bağlı olup olmadığımız . Rails 5 öncesinde, herhangi bir seçenek oluşturulmadan bir kurulum , çocuk bir ebeveyn olmadan var olabilirdi. Bir isteseydik , seçeneği ekleyerek bunu açıkça beyan etmemiz gerekiyordu :belongs_tohas_onehas_manycompositionaggregationbelongs_tobelongs_toaggregationcompositionrequired: true

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

Rails 5'te bu durum değiştirildi. Şimdi, bir belongs_toilişkilendirmenin bildirilmesi compositionvarsayılan olarak bir alt öğe oluşturur; Dolayısıyla yukarıdaki örnek şu şekilde yeniden yazılabilir:

class Room < ApplicationRecord
  belongs_to :house
end

Alt nesnenin bir üst öğe olmadan var olmasına izin vermek istiyorsak, bunu seçenekle açıkça bildirmemiz gerekir. optional

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

Kimden: Remo H. Jansen kitabı “Başlangıç ​​Tepkisi: Öğrenme TypeScript 2.x - İkinci Baskı”:

Biz dernek diyoruz kimin nesneler nesnelerin hiçbir mülkiyet yoktur bağımsız bir yaşam döngüsüne sahiptir bu ilişkileri. Bir öğretmen ve bir öğrenci örneğine bakalım. Birden fazla öğrenci tek bir öğretmenle ilişkilendirilebilir ve tek bir öğrenci birden çok öğretmenle ilişkilendirilebilir, ancak her ikisinin de bağımsız yaşam döngüleri vardır (her ikisi de bağımsız olarak oluşturup silebilir). Dolayısıyla, bir öğretmen okuldan ayrıldığında, hiçbir öğrenciyi silmemize gerek yoktur ve bir öğrenci okuldan ayrıldığında, hiçbir öğretmeni silmemize gerek yoktur.

Toplama , nesneleri bağımsız bir yaşam döngüsüne sahip olan, ancak sahiplik olan ve alt nesneler başka bir üst nesneye ait olamayan ilişkilere diyoruz . Bir cep telefonu ve cep telefonu pili örneğini ele alalım. Tek bir pil bir telefona ait olabilir, ancak telefon çalışmayı durdurursa ve veritabanımızdan silersek, telefon pili silinmeyecektir, çünkü hala işlevsel olabilir. Yani, kümelenmede, mülkiyet varken, nesnelerin yaşam döngüleri vardır

Kompozisyon terimini , nesnelerinin bağımsız bir yaşam döngüsü olmayan ilişkilere atıfta bulunuruz ve üst nesne silinirse, tüm alt nesneler de silinir. Sorular ve cevaplar arasındaki ilişkiye bir örnek verelim. Tek soruların birden fazla yanıtı olabilir ve cevaplar birden fazla soruya ait olamaz. Soruları silersek, cevaplar otomatik olarak silinir.

bağlantı iki ayrı sınıf arasındaki bir ilişkidir ve ilişkilendirme bire bir, bir-mayıs vb. Herhangi bir türde olabilir. Tamamen ayrı iki varlığı birleştirir.

toplanma , örneğin Cüzdan ve Para sınıfları için sınıflar (veya varlıklar) arasında tek yönlü tek yönlü bir ilişki olan özel bir ilişki biçimidir. Cüzdanın Parası var ama para mutlaka Cüzdan'a sahip olmak zorunda değil, bu yüzden tek yönlü bir ilişki. Bu ilişkide, diğeri biterse her iki giriş de hayatta kalabilir. Örneğimizde Wallet sınıfı yoksa Money sınıfının var olamayacağı anlamına gelmez.

Kompozisyon , iki varlığın (veya sınıfları söyleyebilirsiniz) birbirine oldukça bağlı olduğu sınırlı bir Toplama şeklidir. Örneğin İnsan ve Kalp. Bir insanın yaşamak için kalbe ihtiyacı vardır ve kalbin yaşamak için bir İnsan vücuduna ihtiyacı vardır. Başka bir deyişle, sınıflar (varlıklar) birbirine bağımlı olduğunda ve yaşam süreleri aynı olduğunda (eğer biri daha sonra ölürse) bir bileşimdir. İnsan sınıfı yoksa kalp sınıfının bir anlamı yoktur.

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

Kompozisyon: "parçası" ilişkisidir.

örneğin “motor arabanın bir parçasıdır”, “kalp vücudun bir parçasıdır”.

İlişki: “has-a” tipi bir ilişkidir

Örneğin, iki sınıfımız olduğunu varsayalım ki bu iki sınıfın her ikisi de birbirlerinin nesnelerini bir iş için paylaşıyorlarsa ve aynı zamanda birbirlerinin bağımlılığı olmadan var olabilirler veya her ikisi de kendi ömrü.

Yukarıdaki örnek, hem Çalışanın hem de Yönetici sınıfının birbirinin nesnesini ve her ikisinin de kendi bağımsız yaşam döngüsünü kullanması nedeniyle bir ilişki ilişkisini göstermektedir.

Toplama: "has-a" ilişkisine dayanır ve özel bir ilişki biçimidir

örneğin, "Öğrenci" ve "adres". Her öğrencinin bir adresi olmalıdır, böylece Öğrenci sınıfı ve Adres sınıfı arasındaki ilişki “Has-A” tipi ilişki olacaktır, ancak bunun tersi doğru değildir.