Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
[PL] Mentoring DDD: O agregacji i kompozycji (znowu) oraz asocjacji.
Agregacja (a.) i kompozycja (k.) są jednymi z najczęściej wykorzystywanych relacji w UML-owych diagramach klas. Są to specjalizacje asocjacji. Obie oznaczają, iż obiekty jednej z klas ("całość") zawierają referencję do obiektów drugiej klasy ("część"). Kompozycja jest właściwie jedynie silniejszą formą agregacji, w której obiekt zawierający ma pełną kontrolę nad obiektami zawieranymi. W szczególności, czas życia obiekty zawieranych jest limitowany czasem życia obiektu zawierającego.
 
A. i k. oznaczane są na diagramie poprzez linię kończącą się z jednej strony rombem. W a. romb jest biały, w k. zaś - czarny. Jest to intuicyjne, gdyż k. jest silniejsza semantycznie - identyfikowana jest też więc "silniejszym" (ciemniejszym) kolorem. Koniec udekorowany rombem oznacza klasę zawierającą. Możliwe jest dodatkowe doprecyzowanie relacji poprzez określenie krotności relacji po obu stronach linii.
 
Na tym kończy się książkowa definicji i zaczynają trudności. Dalsza część dotyczy agregacji i kompozycji w kontekście DDD i aplikacji zbudowanych w oparciu o bazę danych, co oznacza, że rysowany diagram przedstawia model domeny problemu w formie klas mapowanych do tabel w bazie. Pozwoliłem sobie sporządzić poniższą listę faktów:
  • Informacja o limitowaniu czasu życia przekłada się bezpośrednio na kaskadowanie zapisu oraz usuwania obiektów potomnych w wypadku usunięcia obiektu rodzica. W mapowaniach NHibernate kompozycję poznamy po atrybucie cascade równym "all-delete-orphan" lub mapowaniu typu "component".
  • Relacje dwustronne mogą być modelowane przez parę: kompozycja/agregacja-asocjacja. Ponieważ praktycznie zawsze relacja dwukierunkowa jest modyfikowana tylko z jednej strony, takie rozwiązanie jest bardzo pożyteczne dla programisty. Widać od razu z której strony powinien umieścić metody modyfikujące stan relacji (oczywiście po stronie agregacji/kompozycji).
  • W przypadku relacji n:n można użyć zwykłej pojedynczej asocjacji z odpowiednią notatką. Bardziej komunikatywne wydaje się jednak zastosowanie tego samego podejścia jak dwustronnych relacjach 1:n: pary a./k.-asocjacja.
  • Jednokierunkowa relacja bazodanowa 1:n może w "świecie obiektów" oznaczać dwie rzeczy: kompozycję/agregację (czyli kolekcję obiektów "n" w obiekcie "1") lub asocjację (referencję do obiektu "1" w każdym obiekcie "n"). Są to dwa zupełnie różne modele i jest to według mnie jeden z dowodów na to, że analizę powinno się robić obiektowo, a nie bazodanowo - po prostu świat obiektów jest bogatszy, ma większą siłę wyrazu. W zależności od tego, który z tych modeli przyjmiemy, może się okazać, że nasz model jest świetny lub beznadziejny. W tym poście, w sekcji dotyczącej destylacji modelu przedstawiłem w jaki sposób przejście od podejścia agregacyjnego do asocjacyjnego sprawiło, że model mógł zostać przełożony na wykonywalny kod.

Opublikowane 27 lipca 2009 15:06 przez simon

Komentarze:

# Simon says... : [PL] Mentoring DDD: O agregacji i kompozycji (znowu) oraz asocjacji. @ 27 lipca 2009 18:20

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dotnetomaniak.pl

Komentarze anonimowe wyłączone