Od kilku lat programuję w javie, ostatnio pooglądałem trochę konferencji, poczytałem tematów, postanowiłem zmienić podejście. Mam kilka pytań:
-
Załóżmy, że mamy moduł "Weather", który pozwala nam sprawdzić pogodę dla współrzędnych geograficznych. Mamy jakąś fasadę, która wywołuję metody z serwisu infrastrukturalnego WeatherProvider. Konkretnie dane na temat pogody bierzemy z jakiś KILKU zewnętrznych API, z racji tego, że chcemy te dane jakoś scalać, jeśli nie wszystko jest podane, albo no mamy inny cel w tym, że pogodę bierzemy z kilku API a nie jednego. I teraz w czym jest moja zagwozdka. Załóżmy, że w module Weather mamy dtosa WeatherDto, który prezentuje pogodę i jest zwracany przez wspomniany wcześniej interfejs infrastrukturalny. Intefejs ten jest gdzie indziej implementowany przez kilku klientów API. Tylko sprawa jest taka, że każde API zwraca inną strukturę danych, więc każda implementacja tego intefejsu będzie musiała też zawierać logikę konwersji między zwracaną z API strukturą a moim WeatherDto. No i moje pytanie brzmi czy takie podejście jest ok. Bo oddzielamy się totalnie od klientów API i modułu Weather nie interesuje w ogóle to co zwracana każde z API - logika konwersji na WeatherDto znajduję się w implementacji interfejsu infrastrukturalnego WeatherProvider.
A może lepiej zrobić tak, że dla każdego API zrobić osoby interfejs, który zwraca inną strukturę danych i te konwertery na WeatherDto potraktować jako logikę domeny ? Tylko no wtedy domena pogody jest związana jakoś z implementacją i światem zewnętrznym. -
Do tej pory pisząc RESTy wyglądało to mniej więcej tak, że logika była w serwisach, były jakieś assemblery czy konwertery no i niby wszytko ok, ale budować aplikację zaczynałem od zbudowania encji relacyjnej bazy. Po większej edukacji poczytałem o prawilnym podejściu, że najpierw powinno się budować logikę domeny, a encje bazodanowe powinny być na końcu jako rozwiązanie problemu. Podobnie, że serwisy i wszelkie assemblery to przeczenie obiektowości i pisanie kodu strukturalnego. Zacząłem zatem pisać sobie edukacyjnie jakąś gierkę strategiczno ekonomiczną zaczynając od domeny i strając się nie pisać kodu strukturalnego. Zrobiłem zatem np klasę Building prezentującą budynek z jego kosztem, poziomiem, czasem budowania itd. Nie ma żadnych geterów i seterów - posiada tylko metody biznesowe i wygląda to wszystko ok, ale bardzo dla mnie nieintuicyjne jest to, że ten obiekt jest niby stanowy, jest biznesową encją, ale przecież jego cykl życia to jedno zapytanie http :D I flow wygląda tak: muszę gdzieś pobrać info na temat tego budynku z jakiejś bazy, stworzyć go przez konstruktor, wykonuję biznesową metodę, która zmienia jego stan, czyli np sprawdzam czy można zbudować, rozbudowuję, wyciągam z niego dtosa, robię save w bazie i koniec. Czy to tak powinno wyglądać ?
-
Trochę pytanie powiązane z pkt 2. Mam tą klasę Building. No i doszedłem do tego, że każdy budynek ma inne funkcje - np jedne są kopalniami, jedne produkują jednostki wojskowe, jedne coś przechowują i co tam dalej jeszcze wymyślę. Oczywiście nie będę robił dziedziczenia. Klasa Building zawiera podstawowe dane dla każdego budynku - ValueObjecty typu koszt, czas, nazwa. Resztę jego rzeczy typu to co ma robić, to co potrafi postanowiłem zrobić za pomocą kompozycji .. no i to zrodziło problemy. Mogę np zrobić intefejs Extractable i jego konkretną implementację + implementację NullObjectPattern i tą konkretną powstrzykiwać do jakiś kopalni, a Nullową do Building typu stocznia czy coś, ale jakoś średnio mi się to podoba. Oczywiście taki intefejs Extractable miałby metody typu extract(long dt).. ale jak potem taki Building skompowany zapisać do tabelki w bazie danych ha :D Trochę błądzę .. jakieś rady ?
Java 
Shalomscibi92Shalomnew Cośtam(dane).calculate()też nie będzie obiektowością :P