Ma - Has-a

W projektowaniu baz danych , programowaniu obiektowym i projektowaniu (patrz architektura programu zorientowanego obiektowo ), has-a ( has_a lub has a ) to relacja kompozycji, w której jeden obiekt (często nazywany obiektem utworzonym lub częścią / składową / składową) " należy do „(jest częścią lub składową ) innego obiektu (zwanego typem złożonym) i zachowuje się zgodnie z regułami własności. W prostych słowach, ma-a relacja w obiekcie nazywa pole członkiem obiektu. Wiele relacji ma-a połączy się, tworząc hierarchię zaborczą.

Należy to skontrastować z relacją is-a ( is_a lub jest ), która stanowi hierarchię taksonomiczną ( podtyp ).

Decyzja, czy najbardziej logiczną relacją dla obiektu i jego podrzędnego elementu nie zawsze jest wyraźnie ma-a, czy jest-a . Zamieszanie związane z takimi decyzjami spowodowało konieczność stworzenia terminów metajęzykowych. Dobrym przykładem relacji ma-a są kontenery w C ++ STL .

Podsumowując relacje, mamy

  • hypernym - hiponim ( nadtyp -podtyp) relacje między typami (klasami) określające hierarchię taksonomiczną, gdzie
    • dla relacji dziedziczenia : hiponim (podtyp, podklasa) ma związek typu ( is-a ) z jego hypernym (nadtyp, nadklasa);
  • holonim - meronim (całość / jednostka / część kontenerowa / składnik / element członkowski) relacje między typami (klasami) określające hierarchię dzierżawczą, gdzie
    • dla relacji agregacji (tj. bez własności):
      • holonym (cały) ma HAS w związku z jego meronym (częściowo)
    • dla relacji układowej (tj. z prawem własności):
      • meronim (składnik) ma część związku ze swoim holonimem (podmiotem),
    • na szczelność względem:
  • pojęcie-obiekt (typ-token) relacje między typami (klasami) i obiektami (instancjami), gdzie
    • token (obiekt) ma relację instancji ze swoim typem (klasą).

Przykłady

Model jednostka – relacja

Model jednostka – relacja

W bazach danych relacje ma-a są zwykle reprezentowane w modelu relacji Jednostka . Jak widać na schemacie po prawej stronie, konto może mieć wiele znaków. To pokazuje, że konto ma związek z postacią.

Diagram klas UML

Diagram klas UML
Nadużycia kompozycji i agregacji

W programowaniu obiektowym tę relację można przedstawić za pomocą diagramu klas języka Unified Modeling Language . Ten związek jest również znany jako kompozycja. Jak widać na diagramie klas po prawej, samochód „ma” gaźnik lub samochód „składa się” z gaźnika. Kiedy diament jest zabarwiony na czarno, oznacza to kompozycję , tj. Przedmiot znajdujący się najbliżej diamentu składa się z innego przedmiotu lub go zawiera. Podczas gdy biały diament oznacza agregację , co oznacza, że ​​obiekt najbliżej diamentu może mieć lub posiadać inny przedmiot.

C ++

Innym sposobem rozróżnienia między kompozycją a agregacją w modelowaniu świata rzeczywistego jest rozważenie względnego czasu życia zawartego obiektu. Na przykład, jeśli obiekt Samochód zawiera obiekt Podwozie, podwozie najprawdopodobniej nie zostanie wymienione w okresie eksploatacji samochodu. Będzie miał taką samą żywotność jak sam samochód; więc związek jest relacją kompozycji . Z drugiej strony, jeśli obiekt Samochód zawiera zestaw obiektów Opona, te obiekty Opony mogą się zużywać i wielokrotnie wymieniać. Lub jeśli Samochód stanie się bezużyteczny, niektóre Opony mogą zostać odzyskane i przypisane do innego Samochodu. W każdym razie obiekty opony mają inne okresy życia niż obiekt Samochód; dlatego relacja jest relacją agregacji .

Gdyby utworzyć klasę oprogramowania C ++ w celu zaimplementowania opisanych powyżej relacji, obiekt Car zawierałby kompletny obiekt Chassis w elemencie danych. Ten obiekt Chassis zostałby utworzony w konstruktorze klasy Car (lub zdefiniowany jako typ danych elementu członkowskiego danych i jego właściwości przypisane w konstruktorze). obiekt nie istniałby, gdyby obiekt klasy Car miał zostać usunięty.

Z drugiej strony składowe danych klasy Car, które wskazują na obiekty Tire, byłyby najprawdopodobniej wskaźnikami C ++. Obiekty opon można tworzyć i usuwać zewnętrznie, a nawet przypisywać do elementów danych innego obiektu Car. Obiekty opon miałyby niezależny okres istnienia niezależny od czasu usunięcia obiektu Samochód.

Zobacz też

Uwagi