Ma

W projektowaniu baz danych , programowaniu i projektowaniu zorientowanym obiektowo (patrz obiektowa architektura programu ), has-a ( has_a lub has a ) to relacja kompozycji , w której jeden obiekt (często nazywany obiektem konstytuowanym lub obiektem części/składnika/członka) " należy do” (jest częścią lub członkiem ) innego obiektu (nazywanego typem złożonym) i zachowuje się zgodnie z zasadami własności. W prostych słowach, ma-a relacja w obiekcie nazywana jest polem składowym obiektu. Wiele ma-a połączy się, tworząc hierarchię zaborczą.

Należy to przeciwstawić relacji is-a ( is_a lub is a ), która stanowi hierarchię taksonomiczną ( podtypowanie ).

Decyzja, czy najbardziej logiczną relacją dla obiektu i jego podwładnego nie zawsze jest jednoznacznie ma-a czy jest-a . Zamieszanie wokół takich decyzji spowodowało konieczność stworzenia tych terminów metajęzykowych. Dobrym przykładem relacji ma są kontenery w C++ STL .

Podsumowując relacje, mamy

  • hipernym - hiponim (supertyp-podtyp) relacje między typami (klasami) definiujące hierarchię taksonomiczną, gdzie
    • dla relacji dziedziczenia : hiponim (podtyp, podklasa) ma relację typu ( jest-a ) ze swoim hipernimem (nadtypem, nadklasą) );
  • holonim - meronim (całość/podmiot/pojemnik-część/składnik/człon) relacje między typami (klasami) określające hierarchię dzierżawczą, gdzie
    • dla relacji agregacji (tj. bez własności):
      • holonim (całość) ma związek ma ze swoim meronimem (częścią),
    • dla relacji kompozycyjnej (tj. własnościowej):
      • meronim (składnik) ma związek częściowy ze swoim holonimem (bytem),
    • dla relacji zawierania :
      • meronim (członek) ma związek członka ze swoim holonimem ( pojemnikiem );
  • relacje koncepcja-obiekt (typ-token) między typami (klasami) a obiektami (instancjami), gdzie

Przykłady

Model relacji jednostka-związek

Model relacji jednostka-związek

W bazach danych relacje ma-a są zwykle reprezentowane w modelu Entity-relationship . Jak widać na diagramie po prawej stronie, konto może mieć wiele postaci. To pokazuje, że konto ma związek „ma” z postacią.

Diagram klas UML


Diagram klas UML Nadużycia kompozycji i agregacji

W programowaniu obiektowym związek ten 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 stronie, 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ę po stronie najbliższej diamentowi składa się lub zawiera inny przedmiot. Podczas gdy biały diament oznacza agregację , co oznacza, że ​​obiekt znajdujący się najbliżej diamentu może mieć lub posiadać drugi 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 związkiem kompozycji . Z drugiej strony, jeśli obiekt Car zawiera zestaw obiektów Tyre, te obiekty Tyre mogą się zużywać i być wymieniane kilka razy. Lub jeśli Samochód stanie się niezdatny do użytku, niektóre Opony mogą zostać odzyskane i przypisane do innego Samochodu. W każdym razie obiekty Tyre mają inny czas życia niż obiekt Samochód; zatem związek jest jednym z agregacja .

Gdyby ktoś stworzył klasę oprogramowania C++ w celu zaimplementowania relacji opisanych powyżej, obiekt Car zawierałby kompletny obiekt Chassis w członku danych. Ten obiekt Chassis zostałby utworzony w konstruktorze klasy Car (lub zdefiniowany jako typ danych elementu danych i jego właściwości przypisane w konstruktorze). A ponieważ byłby to całkowicie zawarty element danych klasy Car, obiekt Chassis obiekt przestałby istnieć, gdyby obiekt klasy Car miał zostać usunięty.

Z drugiej strony składowe danych klasy Car wskazujące na obiekty Tyre najprawdopodobniej byłyby wskaźnikami C++. Obiekty Tyre mogą być tworzone i usuwane zewnętrznie, a nawet przypisywane do członków danych innego obiektu Car. Obiekty opon miałyby niezależny okres istnienia, niezależny od momentu usunięcia obiektu samochodu.

Zobacz też

Notatki

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Has-a&oldid=1024380159 ”