Wyjaśnienie asocjacji, agregacji i kompozycji w OOP

Unified Modeling Language (UML) jest de facto standardem modelowania systemów zorientowanych obiektowo. W UML istnieje pięć różnych typów relacji: asocjacja, agregacja, kompozycja, zależność i dziedziczenie. W tym artykule omówiono pierwsze trzy koncepcje, pozostałe pozostawiając w innym wpisie na blogu.

Skojarzenie w programowaniu obiektowym

Asocjacja to słaba semantycznie relacja (zależność semantyczna) między innymi niepowiązanymi obiektami. Skojarzenie to relacja „używania” między dwoma lub więcej obiektami, w których przedmioty mają swój własny czas życia i nie ma właściciela.

Jako przykład wyobraź sobie relację między lekarzem a pacjentem. Lekarz może być powiązany z wieloma pacjentami. W tym samym czasie jeden pacjent może odwiedzać wielu lekarzy w celu leczenia lub konsultacji. Każdy z tych obiektów ma swój własny cykl życia i nie ma „właściciela” ani rodzica. Obiekty, które są częścią relacji skojarzenia, można tworzyć i usuwać niezależnie.

W UML związek asocjacyjny jest reprezentowany przez pojedynczą strzałkę. Relacja skojarzenia może być reprezentowana jako jeden do jednego, jeden do wielu lub wiele do wielu (znany również jako liczność). Zasadniczo związek skojarzeniowy między dwoma lub więcej obiektami oznacza ścieżkę komunikacji (zwaną także łączem) między nimi, tak aby jeden obiekt mógł wysłać wiadomość do drugiego. Poniższy fragment kodu ilustruje, jak dwie klasy, BlogAccount i BlogEntry, są ze sobą powiązane.

klasa publiczna BlogAccount

   {

       prywatne BlogEntry [] blogEntries;

       // Inni członkowie klasy BlogAccount

   }

klasa publiczna BlogEntry

   {

       Int32 blogId;

       napis w postaci napisu;

       tekst tekstowy;

       // Inni członkowie klasy BlogEntry

   }

Agregacja w programowaniu obiektowym

Agregacja to wyspecjalizowana forma powiązania między dwoma lub więcej obiektami, w której każdy obiekt ma swój własny cykl życia, ale istnieje również własność. Agregacja to typowa relacja całość / część lub rodzic / dziecko, ale może, ale nie musi, oznaczać fizyczne ograniczenie. Podstawową właściwością relacji agregacji jest to, że całość lub rodzic (tj. Właściciel) może istnieć bez części lub potomka i odwrotnie.  

Na przykład pracownik może należeć do jednego lub kilku działów w organizacji. Jeśli jednak dział pracownika zostanie usunięty, obiekt pracownika nie zostanie zniszczony, ale będzie żył dalej. Zauważ, że relacje między obiektami uczestniczącymi w agregacji nie mogą być wzajemne - tj. Dział może „posiadać” pracownika, ale pracownik nie jest właścicielem działu. W poniższym przykładzie kodu relacja agregacji jest widoczna między klasami BlogAuthor i BlogAccount.

Klasa publiczna BlogAuthor

   {

       prywatny Int32 authorId;

       prywatny ciąg firstName;

       prywatny ciąg lastName;

       // Inni członkowie klasy BlogAuthor

   }

klasa publiczna BlogAccount

   {

       prywatne BlogEntry [] blogEntries;

       // Inni członkowie klasy BlogAccount

   }

Agregacja jest zwykle reprezentowana w UML za pomocą linii z pustym diamentem. Podobnie jak skojarzenie, agregacja może obejmować relację jeden do jednego, jeden do wielu lub wiele do wielu między uczestniczącymi obiektami. W przypadku relacji jeden do wielu lub wiele do wielu możemy powiedzieć, że jest to relacja nadmiarowa.

Kompozycja w programowaniu obiektowym

Kompozycja jest wyspecjalizowaną formą agregacji. W kompozycji, jeśli obiekt nadrzędny zostanie zniszczony, wówczas obiekty potomne również przestają istnieć. Kompozycja jest w rzeczywistości silnym typem agregacji i czasami jest określana jako relacja „śmierci”. Na przykład dom może składać się z jednego lub więcej pokoi. Jeśli dom zostanie zniszczony, zniszczone zostaną również wszystkie pomieszczenia wchodzące w jego skład. Poniższy fragment kodu ilustruje relację kompozycji między dwiema klasami, House i Room.

klasa publiczna House

{

   pokój prywatny;

   Dom publiczny()

   {

       room = nowy Pokój ();

   }

}

Podobnie jak agregacja, kompozycja jest również całością / częścią lub relacją rodzic / dziecko. Jednak w kompozycji cykl życia części lub dziecka jest kontrolowany przez całość lub rodzica, który jest jej właścicielem. Należy zauważyć, że ta kontrola może być bezpośrednia lub przechodnia. Oznacza to, że rodzic może być bezpośrednio odpowiedzialny za stworzenie lub zniszczenie dziecka lub rodzic może korzystać z dziecka, które zostało już utworzone. Podobnie obiekt nadrzędny może delegować formant do innego elementu nadrzędnego w celu zniszczenia obiektu podrzędnego. Kompozycja jest reprezentowana w UML za pomocą linii łączącej obiekty z pełnym diamentem na końcu obiektu, który jest właścicielem drugiego obiektu.

Mam nadzieję, że ta dyskusja na temat powiązań skojarzeń, agregacji i kompozycji pomogła Ci zrozumieć, czym różnią się te trzy pojęcia. Pamiętaj, że agregacja i kompozycja to podzbiory asocjacji. Zarówno w przypadku agregacji, jak i kompozycji obiekt jednej klasy może być właścicielem obiektu innej klasy. Zarówno w przypadku agregacji, jak i kompozycji obiekty potomne należą do jednego obiektu nadrzędnego, tj. Mogą mieć tylko jednego właściciela.

Wreszcie, w relacji agregacji, cykle życia obiektów macierzystych i obiektów potomnych są niezależne. W relacji kompozycji śmierć obiektu nadrzędnego oznacza również śmierć jego dzieci.