Optional - używać czy nie używać w domenie.

Hej, ostatnio w robocie nastała dyskusja o tym gdzie używać optionala i gdzie nie uzywać. Nawet miałem takie pytanie na rozmowie o pracę - czy prawidłowe jest używanie optionali w dtosach, które idą na GUI.

No bo tak, wg mnie sensowne jest używanie tego jako zwrotki metod albo argumenty metod jeśli w obu tych przypadkach uzasadnione jest zwrócenie/przekazanie do metody nulla. Wiemy dodatkowo dzięki temu, że coś może być nullem.

Jak to jest z użyciem optionali w domenie ? I też pytanie czy domeną nazywa się obiekty domenowe z DDD czy encje JPA, bo widzę, że wiele osób domeną określa to drugie, a wszelkie klasy z logiką to serwisy bezstanowe :O. Nie widzę tego ja pole klasy, jedynie jako getter, chociaż tych staram się nie używać.

W dtosach zwracanych na GUI też nie widzę optionala, ale nie umiem konkretnie wytłumaczyć dlaczego. Wg mnie, front sam powinien obsłużyć jeśli jakieś pole nie przychodzi. Poza tym optionale są nieserializowane, ale nie wiem czy to jest odp na to pytanie.

Co z dtosami wejściowymi do systemu z frontu ? Tj. formularzami. Czy tutaj stosowanie Optionali jest ok ? Jackson umie to obsłużyć.

jak z frontu wpada cos lub nie wpada to na getterach wrapowalem to Optional.ofNullable() i HEJA DO REPO xD

Sprawa jest ciekawa. W teorii optional ma zaznaczone, że powinen być używany tylko jako return z metody i jest neserializowalny. W praktyce null jest gorszy.
Rozwiązanie to Option z Vavr lub Optional z guavy, który jak najbardziek mam w domenie /dto.
Mappery vavr/option do jsona są. Do hibernate/jpa nie wiem.

Moim zdaniem nie ma sensu. Trzeba zakładać defensywnie że każde możliwe property które przychodzi z RESTa jest nullem. Bo moze nim być. Więc należy kod konsumujący te dane napisać tak, żeby brać to pod uwagę. I tutaj nijak nie pomaga to czy mamy Optional czy go nie mamy. Jedyny plus optionala jest taki, że informuje nas że "dane pole moze być puste" już na etapie typesystemu, ale w przypadku łykania jakiegoś wejścia z jsonem musimy założyć że każde pole może być puste, więc optional jest tu redundantny.
Co więcej, może to być nawet mylące! Bo ktoś popatrzy i uzna, że o! to pole może być puste, to dam checka na isPresent() ale zrobi tak tylko z tymi optionalami, a potem dostanie jsona bez jakiegoś innego pola i się skrypt wysypie.

Shalom napisał(a):

Co więcej, może to być nawet mylące! Bo ktoś popatrzy i uzna, że o! to pole może być puste, to dam checka na isPresent() ale zrobi tak tylko z tymi optionalami, a potem dostanie jsona bez jakiegoś innego pola i się skrypt wysypie.

Nie zgadzam się. Wiele zależy od krytyczności skryptu, W typowym front/back, kiedy api jest wewnętrzne, możemy sobie odpuścić dodatkowe sprawdzanie i ładnie wywalać się 500tką :-) jak dane są niepoprawne (czyli gdy przychodzi null).

W publikowanym api fakt, że warto sprawdzać i walidować wszystko, ale czy tam są optionalle czy nie - zapomnieć można tak samo.
Poza tym opcja full wypas to : https://github.com/java-json-tools/json-schema-validator

ale czy tam są optionalle czy nie - zapomnieć można tak samo.

Toteż właśnie o tym pisałem :) Że ten optional zupełnie nam w takiej sytuacji nic nie daje. No i oczywiście chodziło mi tutaj raczej o sytuacje kiedy dane są wysyłane przez coś od nas niezależnego. Jak nam własny backend coś głupiego wysyła to niech leci 500.

Optional w DTO do komunikacji z GUI jak najbardziej OK, ale jeśli korzystamy z Jackson datatype jdk-8. Wtedy mamy serializacje i deserializacje do Optionali z automatu.

Niestety lombok nie wspiera Optional gettera, mimo że jest to bardzo pożądany feature przez wielu ludzi:

https://github.com/rzwitserloot/lombok/issues/1214

Optional jako pole nie jest okey. Nawet Intellij IDEA - najmądrzejsze IDE do Javy na świecie od razu to podkreśla. Przytaczając cytat https://stackoverflow.com/a/29033935 :

Of course, people will do what they want. But we did have a clear intention when adding this feature, and it was not to be a general purpose Maybe or Some type, as much as many people would have liked us to do so. Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result", and using null for such was overwhelmingly likely to cause errors. The key here is the focus on use as a return type. The class is definitively not intended for use as a property of a Java Bean. Witness to this is that Optional does not implement Serializable, which is generally necessary for widespread use as a property of an object.

O czym innym mówimy.

Czyli ogólnie lepiej używać Optionali z Guavy lub Vavra niż tych standardowych ?

A skorzystam z tematu i zapytam .. jakich bibliotek warto używać w projektach i co konkretnie z nich ? Guava, Vavr ? Coś jeszcze ? Co tam jest godnego polecenia ?

Lepiej używać Optionala z Javy. Jak zobaczysz javadoca do guavy, to tam sugerują, żeby zamiast ichniego Optionala używać standardowego.

https://google.github.io/guava/releases/19.0/api/docs/com/google/common/base/Optional.html

xLatency napisał(a):

Lepiej używać Optionala z Javy. Jak zobaczysz javadoca do guavy, to tam sugerują, żeby zamiast ichniego Optionala używać standardowego.

https://google.github.io/guava/releases/19.0/api/docs/com/google/common/base/Optional.html

Czyli lepiej używać Vavrowego :)

Szczerze mówić w Javie nie widzę wielkiego pola do dyskusji. Option + Either z VAVRa i całkiem inaczej się pisze systemy.

Pytanie to jest Kotlin i nullable type - czy używać pytajnika?
Nie używam, (na korzyść Option). Częsciowo powodowane jest to chęcią zachowania 100% łatwości integracji z Javą.
Częściowo miłością do Monad. ... Ale mam takie przeczucie, że to niekoniecznie dobrze.

@karolinaa: no akurat brak normalnego optionala i ciezkie uzupelnianie nazw przez ide to są dosyć powazne problemy, ale np. defaultowo zamknieta klasa spoko