Nadmiarowe użycie optionali w springowym repository

Charles_Ray napisał(a):

Jeśli zależy Ci na większej „ekspresji typów” to pewnie Vavr będzie dobrym kierunkiem. Tylko wtedy wchodzisz w Eithery, mapy, flatmapy co tez ma swoją wysoka cenę jeśli chodzi o czytelność. Jak zawsze - trade off.

Można używać Vavr i nie używać Either. IHMO dla samych kolekcji warto używać Vavr.
BTW mapy i flatmapy są też dla Optional. Kto nie flatmapował Optionala ten jeszcze nie używał go w pełni :P

Tak, ale wtedy mówimy raczej o punktowym użyciu tych operatorów (w ramach metody, klasy), nie latają przez wszystkie warstwy itd jak w podejściu reaktywnym. Przynajmniej taka jest moja percepcja tego tematu :)

Koziołek napisał(a):

@grzechup: ja zadam ci inne pytanie. Załóżmy na chwilę, że zamiast Optional masz null i możesz dowolnie rzucać NPE.

Czy fragment:

Kopiuj

if(!opt.Company == null){
 return Response.create(ResultCode.COMPANY_NOT_EXIST);
}

będzie występować w twoim kodzie?

Tak, co imo byłoby i tak lepsze bo wtedy zniknęła by wszędzie w takich miejscach linijka opt.Company.get(), co uszczupliło by kod całkowicie o kilkadziesiąt linijek.

Po co jednak używasz Optional.get? Co do zasady nie rozpakowujemy kontenera takiego jak Optional, bo możemy źle skończyć. Zamiast tego można użyć Optional.map i w ten sposób modyfikować wartość.

Zamiast kodu:

Company zBazyDancych(){
    //…
   var optCompany = zapytanie();
   // …
   Company company = optCompany.get();
   company = zróbFikuMiku(company);
   // …
   return company;
}

Można napisać:

Optional<Company> zBazyDancych(){
    //…
   var optCompany = zapytanie();
   // …
   return optCompany.map(this::zróbFikuMiku);
}

Jeżeli potrzebujesz się dostać do bebechów Company, to zawsze możesz użyć Optional.flatMap. Jak już wspomniałem. Nie ma potrzeby wypakowywania kontenera.