UML'de kompozisyon ve toplama arasındaki farkı anlamakta zorlandım. Lütfen birisi bana aralarında iyi bir karşılaştırma ve zıtlık önerebilir mi? Kodda aralarındaki farkı tanımayı ve / veya kısa bir yazılım / kod örneği görmeyi de öğrenmek isterim.
Düzenleme: Sormamın nedenlerinden biri, işte yaptığımız ters dokümantasyon etkinliği yüzünden. Kodu yazdık, ancak geri dönüp kod için sınıf diyagramları oluşturmamız gerekiyor. Dernekleri doğru bir şekilde yakalamak istiyoruz.
Yanıtlar:
Toplama ve kompozisyon arasındaki ayrım bağlama bağlıdır.
Başka bir cevapta bahsedilen araba örneğini ele alalım - evet, bir araba egzozunun "kendi başına" durabileceği doğrudur, bu yüzden bir araba ile kompozisyon içinde olmayabilir - ancak uygulamaya bağlıdır. Bağımsız araba egzozları ile gerçekten uğraşması gereken bir uygulama geliştirirseniz (bir araba mağazası yönetim uygulaması mı?), Toplama sizin seçiminiz olacaktır. Ancak bu basit bir yarış oyunuysa ve araba egzozu yalnızca bir arabanın parçası olarak hizmet ediyorsa - peki, kompozisyon oldukça iyi olurdu.
Satranç tahtası? Aynı sorun. Bir satranç taşı satranç tahtası olmadan sadece belirli uygulamalarda mevcut değildir. Diğerlerinde (bir oyuncak üreticisininki gibi), bir satranç taşı kesinlikle bir satranç tahtasında oluşturulamaz.
Kompozisyonu / toplamayı en sevdiğiniz programlama diliyle eşleştirmeye çalışırken işler daha da kötüleşir. Bazı dillerde, farkın fark edilmesi daha kolay olabilir (işler basit olduğunda "referansa göre" ve "değere göre"), ancak diğerlerinde hiç mevcut olmayabilir.
Ve son bir tavsiye? Bu konuda çok fazla zaman kaybetmeyin. Buna değmez. Bu ayrım pratikte pek kullanışlı değildir (tamamen açık bir "kompozisyona" sahip olsanız bile, teknik nedenlerden dolayı - örneğin, önbelleğe alma) onu bir toplama olarak uygulamak isteyebilirsiniz.
Kural olarak:
class Person {
private Heart heart;
private List<Hand> hands;
}
class City {
private List<Tree> trees;
private List<Car> cars
}
Kompozisyonda (Kişi, Kalp, El), "alt nesneler" (Kalp, El) Kişi yok edilir edilmez yok edilecektir.
Toplamadaki (Şehir, Ağaç, Araba) "alt nesneler" (Ağaç, Araba) Şehir yok edildiğinde yok EDİLMEZ.
Sonuç olarak, bileşim karşılıklı varoluşa vurgu yapar ve kümelenmede bu özelliğe gerek YOKTUR.
Bileşim ve Toplama, ilişkilendirme türleridir. Çok yakından ilişkilidirler ve programlama açısından ikisi arasında pek bir fark görünmüyor. Bu ikisi arasındaki farkı java kod örnekleri ile açıklamaya çalışacağım.
Toplama : Nesne diğerinin dışında bulunur, dışarıda oluşturulur, bu nedenle yapıcıya bir argüman (örneğin) olarak iletilir. Ör: İnsanlar - araba. Araba farklı bir bağlamda yaratılır ve ardından bir kişisel mülk haline gelir.
// code example for Aggregation:
// reference existing HttpListener and RequestProcessor
public class WebServer {
private HttpListener listener;
private RequestProcessor processor;
public WebServer(HttpListener listener, RequestProcessor processor) {
this.listener = listener;
this.processor = processor;
}
}
Kompozisyon : Nesne yalnızca var olur veya diğerinin bir parçası olarak yalnızca diğerinin içinde anlam ifade eder. Ör: İnsanlar - kalp. Bir kalp yaratmaz ve sonra onu bir kişiye vermezsiniz. Bunun yerine kalp, insan yaratıldığında yaratılır.
// code example for composition:
// create own HttpListener and RequestProcessor
public class WebServer {
private HttpListener listener;
private RequestProcessor processor;
public WebServer() {
this.listener = new HttpListener(80);
this.processor = new RequestProcessor(“/www/root”);
}
}
Burada bir örnekle açıklanmıştır Toplama ve Kompozisyon arasındaki Fark
Kompozisyon, alt nesnelerin ebeveyn ile bir ömür paylaştığı anlamına gelir. Toplama yapmaz. Örneğin, bir satranç tahtası satranç karelerinden oluşur - satranç kareleri tahta olmadan gerçekten var olmaz. Bununla birlikte, araba bir parçaların toplamıdır - o sırada bir arabanın parçası değilse, araba egzozu hala bir araba egzozudur.
Öğrendiğim örnek, ele parmaklardı. Eliniz parmaklardan oluşuyor. Onların sahibi. El ölürse parmaklar ölür. Parmakları "birleştiremezsin". Gidip fazladan parmaklarınızı alıp dilediğiniz zaman takıp elinizden ayıramazsınız.
Tasarım açısından buradaki değer, başka bir posterin söylediği gibi, genellikle nesne ömrü ile ilgilidir. Bir Müşteriniz olduğunu ve bir Hesabı olduğunu varsayalım. Bu Hesap, müşterinin "oluşturulmuş" bir nesnesidir (en azından, aklıma gelen çoğu bağlamda). Müşteriyi silerseniz, Hesabın kendi başına bir değeri olmaz, dolayısıyla hesap da silinir. Bunun tersi genellikle nesne yaratmada doğrudur. Bir Hesap yalnızca bir Müşteri bağlamında bir anlama sahip olduğundan, Müşteri oluşturmanın bir parçası olarak Hesap oluşturmayı gerçekleştirirsiniz (veya bunu tembel yaparsanız, bu bazı Müşteri işlemlerinin bir parçası olur).
Tasarımda, diğer nesnelere sahip olan (oluşturan) nesneler ile yalnızca diğer nesnelere referans veren (toplayan) nesneler hakkında düşünmek yararlıdır. Nesne oluşturma / temizleme / güncellemeler için sorumluluğun nerede olduğunu belirlemeye yardımcı olabilir.
Kodda olduğu gibi, genellikle söylemek zor. Koddaki çoğu şey bir nesne referansıdır, bu nedenle başvurulan nesnenin oluşturulmuş (sahip olunan) veya toplanmış olup olmadığı açık olmayabilir.
Parça-bütün ilişki kavramlarının bir araya getirilmesi ve bileşimi arasındaki ayrım konusunda bu kadar kafa karışıklığı olması şaşırtıcı . Temel sorun, kompozisyon kavramının, 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ığı anlamına geldiğine dair yaygın yanlış anlaşılmadır (uzman yazılım geliştiricileri arasında ve UML'nin yazarları arasında bile). Ancak bu görüş, parçaların bütünden ayrılabileceği ve bütünün yok edilmesinden sonra hayatta kalabileceği, paylaşılamaz parçalara sahip kısmi-bütün birliktelikleri olgusunu görmezden geliyor.
UML şartname belgesinde, "kompozisyon" teriminin tanımı her zaman paylaşılamayan kısımları ima etmiştir, ancak "kompozisyon" un tanımlayıcı özelliğinin ne olduğu ve sadece isteğe bağlı bir özellik olduğu açık olmamıştır. Yeni sürümde (2015 itibariyle) UML 2.5, "kompozisyon" teriminin tanımını iyileştirme girişiminden sonra bile belirsizliğini koruyor ve paylaşılamaz ile parça-bütün ilişkilerinin nasıl modelleneceği konusunda herhangi bir rehberlik sağlamıyor Parçaların ayrılamadığı ve bütünle birlikte imha edildiği durumun aksine, parçaların bütünden ayrılabildiği ve yok edilmesine dayanabildiği parçalar. Onlar söylüyor
Bileşik bir nesne silinirse, nesneler olan tüm parça örnekleri onunla birlikte silinir.
Ama aynı zamanda diyorlar ki
Bileşik nesne silinmeden önce bir parça nesne, bileşik nesneden kaldırılabilir ve bu nedenle, bileşik nesnenin bir parçası olarak silinemez.
Bu karışıklık, bileşenler ve bileşikler arasındaki yaşam döngüsü bağımlılıklarını hesaba katmayan UML tanımının eksikliğine işaret ediyor. Bu nedenle , bileşenlerin kendi kompozitlerinden ayrılamayacağı ve bu nedenle, kompozitleri yok edildiğinde imha edilmesi gereken << ayrılmaz >> bileşimler için bir UML klişesi getirilerek UML tanımının nasıl geliştirilebileceğini anlamak önemlidir .
As Martin Fowler açıkladı , kompozisyon karakterizasyonu için ana konu "bir nesne yalnızca bir kompozisyon ilişkinin parçası olabilir" olmasıdır. Bu aynı zamanda Geert Bellekens tarafından UML Oluşturma, Toplama ve İlişkilendirme arasındaki mükemmel blog gönderisinde de açıklanmıştır . Bir kompozisyonun bu tanımlayıcı özelliğine ek olarak ( münhasır veya paylaşılamaz kısımlara sahip olmak), bir kompozisyon ayrıca kompozit ve bileşenleri arasında bir yaşam döngüsü bağımlılığı ile gelebilir. Aslında, bu tür iki tür bağımlılık vardır:
Personve arasındaki bileşim ile örneklendirilir Heart. Bir kalp, sahibi öldüğünde ya yok edilir ya da başka birine nakledilir.Personve arasındaki bileşimdir Brain.
Özetle, yaşam döngüsü bağımlılıkları yalnızca belirli kompozisyon durumları için geçerlidir, ancak genel olarak değil, bu nedenle tanımlayıcı bir özellik değildir.
UML spesifikasyonu şunu belirtir: "Bileşik örnek silinmeden önce bir parça bileşik bir örnekten kaldırılabilir ve bu nedenle bileşik örneğin parçası olarak silinemez." Bir örnekte Car- Engineaşağıdaki şemada gösterildiği gibi bileşim, bu motoru motor yok değildir ve tekrar kullanılabilir ve bu durumda araç yok olmadan önce, araç, ayrılabilir bu durum net bir şekilde var. Bu, kompozisyon çizgisinin bileşik tarafındaki sıfır veya bir çokluk ile ifade edilir.
Çokluk bileşik tarafında bir bileşimin ilişki ucunun ya 1 ya da 0..1 olup, bileşenler zorunlu bileşik varsa gerçeğine bağlı olarak (bir kompozit bağlanmış olmalıdır) ya da. Bileşenler ayrılamazsa , bu, zorunlu bir bileşime sahip oldukları anlamına gelir.
Bir toplama, bir bütünün parçalarının diğer bütünlerle paylaşılabildiği bir parça-bütün ilişkisinin amaçlanan anlamı ile başka bir özel ilişkilendirme biçimidir. Örneğin, sınıflar arasında bir toplama modelleyebilir DegreeProgramve Courseaşağıdaki şemada gösterildiği gibi bir ders derece programının bir parçası olan ve bir programı, örneğin, bir mühendislik derecesi C paylaşabilir (iki ya da daha fazla derece programları arasında paylaşılabilir, çünkü, bilgisayar bilimleri derecesi ile programlama kursu).
Bununla birlikte, paylaşılabilir parçalarla bir toplama kavramı gerçekten çok fazla bir şey ifade etmiyor, bu nedenle uygulama üzerinde herhangi bir etkisi yoktur ve bu nedenle birçok geliştirici, sınıf diyagramlarında beyaz elmas kullanmayı tercih etmez, sadece basit bir ilişkilendirmeyi modelleyin. yerine. UML belirtimi şöyle der: "Paylaşılan toplamanın kesin semantiği, uygulama alanına ve modelleyiciye göre değişir".
Çokluk bütün tarafında bir toplama birliği ucunun herhangi bir sayıda (*) bir parçası olan ya çünkü olabilir ortak bütünler, herhangi bir sayıda, yanı.
Kod terimlerinde, kompozisyon genellikle içerdiği nesnenin bileşenin * örneklerini oluşturmaktan sorumlu olduğunu ve içerdiği nesnenin ona yalnızca uzun ömürlü referansları tuttuğunu önerir. Bu nedenle, üst nesnenin referansı kaldırılır ve çöp toplanırsa, çocuk da öyle.
yani bu kod ...
Class Order
private Collection<LineItem> items;
...
void addOrderLine(Item sku, int quantity){
items.add(new LineItem(sku, quantity));
}
}
LineItem'in Order - LineItems'in bir bileşeni olduğunu gösterir. Ancak Öğe nesneleri sırayla oluşturulmaz - gerektiği gibi aktarılırlar ve mağazada sipariş olmasa bile var olmaya devam ederler. bu nedenle bileşenler yerine ilişkilendirilirler.
* nb konteyner bileşeni tanıtmaktan sorumludur , ancak aslında yeni ... () olarak adlandırılmayabilir - bu java, genellikle ilk önce geçilmesi gereken bir veya iki fabrika vardır!
Diğer yanıtlarda verilen kavramsal çizimler yararlıdır, ancak yararlı bulduğum başka bir noktayı daha paylaşmak istiyorum.
İlişkisel veritabanı için kaynak kodu veya DDL için kod üretimi için UML'den biraz mesafe aldım. Orada, bir tablonun kodumda boş değer atanamayan bir yabancı anahtar (veritabanında) ve boş değer atanamayan bir "ana" (ve genellikle "son") nesnesi olduğunu belirtmek için kompozisyon kullandım. Bir kaydın veya nesnenin "öksüz" olarak var olmasını, herhangi bir ana nesneye eklenmemesini veya farklı bir ana nesne tarafından "benimsenmesini" istediğim durumlarda toplamayı kullanıyorum.
Başka bir deyişle, model için kod yazarken ihtiyaç duyulabilecek bazı ekstra kısıtlamaları belirtmek için bir kısaltma olarak kompozisyon gösterimini kullandım.
Sevdiğim örnek: Kompozisyon: Su, Gölet'in bir parçasıdır . (Gölet, suyun bileşimidir.) Toplanma: Gölette ördek ve balık bulunur (Gölet , ördekler ve balıkları bir araya getirir)
Gördüğünüz gibi "parçası" ve "sahip" kelimelerini kalın harflerle yazdım, çünkü bu 2 cümle tipik olarak sınıflar arasında ne tür bir bağlantı olduğuna işaret edebilir.
Ancak başkalarının da belirttiği gibi, çoğu zaman bağlantının bir bileşim mi yoksa bir toplama mı olduğu uygulamaya bağlıdır.
Toplam ilişki ile bileşik ilişki arasında bir fark yapmak çok zor, ama bazı örnekler alacağım, bir evimiz ve odalarımız var, burada bileşik bir ilişkimiz var, oda evin bir parçası ve oda hayatı başladı ev hayatı ve Ev hayatı bittiğinde bitecek, oda evin bir parçasıdır, ülke ve başkent, kitap ve sayfalar gibi kompozisyon hakkında konuşuruz. Toplu ilişki örneği için, takım ve oyuncuları alın, oyuncu takımsız var olabilir ve takım bir grup oyuncudur ve oyuncu hayatı takım hayatından önce başlayabilir, programlama hakkında konuşursak, oyuncular yaratabiliriz ve sonra takım oluşturacağız, ama kompozisyon için hayır, evin içinde odalar yaratıyoruz. Kompozisyon ----> kompozit | besteleme. Toplama -------> grup | element
Şartları belirleyelim. Aggregation, UML standardında bir metatermdir ve basitçe paylaşılan olarak adlandırılan HER İKİSİ bileşim ve paylaşılan toplama anlamına gelir . Genellikle yanlış "toplama" olarak adlandırılır. KÖTÜ, çünkü kompozisyon da bir kümelenmedir. Anladığım kadarıyla "paylaşılan" demek istiyorsun.
UML standardından daha fazlası:
bileşik - Özelliğin bileşik olarak toplandığını, yani bileşik nesnenin, oluşturulan nesnelerin (parçaların) varlığı ve depolanmasından sorumlu olduğunu belirtir.
Yani, üniversiteden kathedralara derneği bir kompozisyondur, çünkü cathedra üniversite dışında yoktur (IMHO)
Paylaşılan toplamanın kesin anlam bilgisi, uygulama alanı ve modelleyiciye göre değişir.
Yani, diğer tüm dernekler, yalnızca kendinizin veya başka birinin bazı ilkelerini takip ediyorsanız, paylaşılan toplamalar olarak çizilebilir. Ayrıca buraya bakın .
Böbrek, karaciğer, beyin gibi insan vücudunun parçalarını düşünün. Burada kompozisyon ve birleştirme kavramlarının haritasını çıkarmaya çalışırsak, şöyle olur:
Böbrek ve karaciğer gibi vücut parçaları naklinin ortaya çıkmasından önce, bu iki vücut parçası insan vücudu ile kompozisyon içindeydi ve insan vücudu ile izole olamazdı.
Ancak vücut parçası naklinin ortaya çıkmasından sonra, başka bir insan vücuduna nakledilebilirler, bu nedenle bu parçalar insan vücuduyla bir araya gelerek insan vücuduyla izole bir şekilde varolmaları artık mümkündür.