część 1
część 2
Dziękuję wszystkim za aktywne uczestnictwo:)
//================================
Nawiązanie do community .NET jako przodującego w poszukiwaniu nowych (a może klasycznych?) i lepszych metod modelowania jest zabiegiem celowym, mającym na celu zdopingowanie Was do działania.
11 komentarzy:
Jest możec szansa na slajdy z prezentacji?
proszę bardzo: http://www.dworld.pl/static/nyac/v1_Krakow/DDD%20-%20everything%20on%20place%20and%20place%20for%20everything.pdf
Sławek,
Twoje poczucie humoru nieodmiennie rozbawia mnie do łez :D
Świetna prezentacja!
Dzięki,
mb
p.s. pisałem o filmikach
Dzięki:)
Zgodnie z moją maksymą: nauka i zabawa to to samo.
Bardzo interesujące,
Zastanowiłą mnie jedna twoja wypowiedź:
"...zróbmy sobie klasę Money niech ona potrafi się przeliczyć na inną walutę..." (44 minuta 1 części)
Zastanawiam się, czy nieanemiczne encje powinny przełamywać naturalny porządek przypisywania funkcjonalności do obiektów, gdzie w rzeczywistości to obiekt kalkulator potrafi przeliczać waluty (a nie sam pieniądz).
Dało mi to też do myślenia, nad tematem rodzielenia funkcjonalności(metod) przypisanych do obiektów vs metod bisnesowych w serwisach. Klasy serwisów pachną "workiem", gdzie wrzucamy niepasujące nigdzie metody.
Bardziej naturalnym podejściem byłoby np. podzielenie encji na dwie grupy:
- dead entities, przykłady: cegła, faktura, dokument i z twojego przykładu pieniądz
- alive entities, przykłady: murarz, księgowy, pisarz i z twojego przykładu kalkulator (coś jak "rule' w Data Context Interaction)
(nie jest to podział na anemic/nonanemic entities)
Powaracając do tematu waluty...
A może widzisz zysk w tym, aby w modelowaniu nie hamować się rzeczywistymi barierami odziedziczonymi z natury, których w sofcie nie mamy?
Z tym przeliczaniem walut w Money to tylko taki przykład, ale:
to zależy...
od domeny, bo
1. w domenie, gdzie pieniądze są tylko dodatkiem, zgodzę się z Twoim podejściem - obciążanie Money taką ciężką odpowiedzialnością jest słabym designem
2. w domenie, gdzie wszystko kręci się woków pieniądza podejście, które sugerujesz doprowadzi do czegoś w stylu Feature Envy http://en.wikipedia.org/wiki/Code_smell
Jakimś kompromisem w domenie typu 2 (gdy w wielu miejscach dochodzi do przeliczeń) jakimś kompromisem może delegowanie obliczeń do kalkulatora.
Ale oczywiście tutaj się nie upieram, bo podejście 1 nie jest krytyczną decyzją projektową.
Co do dead/alive encj:
Building Blocki z DDD traktuję tylko jako punkt wyjściowy. Nic nie stoi na przeszkodzie, aby dodawać własne rodzaje bloków.
Stoi za tym szersza koncepcja: Responsibility Driven Design http://en.wikipedia.org/wiki/Responsibility-driven_design (jest też książka po polsku).
W RDD określasz sobie jakby stereotypy dla klas i później się tego trzymasz podejmując decyzję o wprowadzeniu nowej klasy - trzeba sobie odpowiedzieć na pytanie jaką rolę ma ona pełnić.
I właśnie w RDD są sugerowane między innymi takie role jak: kontener danych oraz transformator danych. To odpowiadałoby Twojemu przykładowi.
Co do ostatniego pytania: czy chodzi o to czy w modelu mogą pojawiać się byty nie mające odpowiednika (albo dokładnego "kształtu) jak w świecie rzeczywistym?
Jeżeli o to chodzi, to odpowiedź jest prosta: tak. Mało tego: wprowadzanie "czystych fabrykatów" jest jedną z technik GRASP: http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Pure_Fabrication
Dzięki nim można osiągnąć bardziej giętki (otwarty na rozbudowę) design (np strategie), zwiększyć drastycznie testowalność kodu (zastąpienie operatora new fabrykami) itd...
gościu, napisz jakiegoś ciekawego posta :)
Posta w ogóle czy na temat z wątku?
Ehhh zmęczony mocno jestem po ostatnim pracowitym tygodniu... Kilka dni grania w Killzone 3 powinno przywrócić siły do pisania (i myślenia w ogóle) - wówczas coś napiszę.
to ja teraz czekam na odwiedziny w SilesiaJUG :PP
ok, będę pamiętał o zaproszeniu gdy tylko na horyzoncie pojawi się wyjazd do Silesii.
Prześlij komentarz