Çözüldü Java Optional ile Modeli ne zaman kullanmak gerekir?

bitwise dedi:

Aslinda genel olarak ne zaman Optional kullanmaliyiz ile ayni soru bu. JPA sadece bu yapiya uyum sagliyor.

Eger kodun geri kalaninda fluent fonksiyonel programlama yapiliyorsa Optional kullanmak yegdir.

Yine interface'e bakan kisi, bu alanin "null" olabilecegini tek okuyusta anlayabilmis olur. Kotlinde oldugu gibi nullable olmayan tipler Java'da @NonNull gibi annotasyonlar disinda tanimlanamadigi icin Optional olmayan return parametresinin null olmadigini varsayarim ben. Aksi halde kodun her tarafi " x != null" kontrolleri ile dolu olur.

Optional kullanarak interface i implemente eden ve kullanan insanlara bu alanin null olabilecegini ve null durumu handle etmelerini zorunlu kilmis olursun bu da kod kalitesini arttirir.

Ancak Optional da silver bullet degil; != yerine ifPresent() kullanarak semantik olarak ayni seyi farkli sekilde yapmis oluyorsun. Sadece daha okunabilir olmus oluyor. Ayrica ufak da olsa bir performans farki da var, surekli wrapper yaptigin icin. Son aklima gelen dezavantaj da serialization. Optional<Type> serialize etmek icin biraz daha ugrasman gerekiyor direkt Type serializasyonuna kiyasla.

Isminde "findBy" gectigi icin Optional<Account> olmali. Bunu yaparak bu fonksiyonu cagiran her yerde Account bulunamama durumunu handle etmeye zorlamis oluyorsun ki olmasi gereken bu. Cagiran yer de isterse bunu kendisi handle eder isterse o da kendisini cagiran yere delege eder.

Direkt "Account findByEmail()" seklinde yaparsan cagiran yerde null-safety zorlamasi olmaz. Bazen null bazen null olmayan tipler genel olarak proje buyudukce basa bela olurlar.

Genişletmek için tıkla...

706111 dedi:

Birde hocam Optional ile yaptığımız basit exceptionları, orElseThrow ile fırlatmamıza izin veriyor. Tıpkı findByID gibi JPA Repository'de var olan fonksiyon gibi.

Genişletmek için tıkla...

bitwise dedi:

Evet.

Ya da birden fazla Optional<Type> fonksiyonunu fall back yapabilirsin. Mesela findByEmail() ile bulunamazsa findByName() ile aransin gibi.

findByEmail().or(()->findByName()) gibi. Closure kullanip bunlari sadece gerektigi zaman execute edebilir hale getirebilirsin. flatMap() ya da stream() API'lari ile birlestirebilirsin. Optional<> kullanmanin fonksiyonel faydasi cok.

Ama neticede bir fonksiyonun null dondugu zaman ne yapman gerektigini farkli sekilde yapmis oluyorsun, bir sekilde yaptigini otekiyle de yaparsin. Sahsen ben Optional<> yerine Kotlin'deki Type? yapisini tercih ederim. Neyin nullable, neyin NotNull oldugu compile edilirken belli olmali.

Genişletmek için tıkla...

706111 dedi:

Hocam nullabe ve notnull, DTO için kullanılmıyor mu? Mesela dışarıdan veri alacağız. Bunun için DTO modeli oluşturduk. Birkaç değişkenini @Notnull diye işaretliyoruz Java'da.

Genişletmek için tıkla...

bitwise dedi:

Javax @NotNull annotasyonunu kastediyorsan evet. Sadece DTO icin degil fonksiyonlar icin de kullanilabilir.

NotNull (Java(TM) EE 7 Specification APIs)

docs.oracle.com

Ancak burada runtime vs compile time ayrimini iyi anlamak gerek. Sen bir parametreyi ya da field'i @NotNull olarak isaretleyebilirsin fakat bunu process eden birileri olmazsa onlar null olabilirler. Runtime sirasinda data geldiginde eger isaretli alan null ise hata veren bir mekanizmaya ihtiyacin var. Spring bunu yapiyor, Hibernate de yapiyor. Baska yapan reflection kutuphaneleri de var.

Konuda onceden tartistigimiz Optional<> muhabbeti compile time bir olay.

Yine IDEA'nin kendi @NotNull annotasyonu da var. Compile zamanda hata alirsin eger dogru sekilde ayarladiysan build konfigurasyonunu.

Annotations | IntelliJ IDEA

www.jetbrains.com

Genişletmek için tıkla...

706111 dedi:

Teşekkür ettim hocam. Compile time ile runtime konularını da iyice öğreneyim.

Genişletmek için tıkla...

bitwise dedi:

Rica ederim. Cok bir numarasi yok; birisi kodunu compile ettigin zaman, digeri programin calisirken.

Eger bir hata alinacaksa bunu en hizli ve en erken sekilde almak daha iyidir. Kod calisirken NullPointerException yemektense compile sirasinda "Haci sen null olmayan alana null assign etmeye calisiyorsun" diye hata alman cok fazla zaman ve kalite kazandirir.

Fail-Fast felsefesi. Fail fast (business) - Wikipedia

Genişletmek için tıkla...

    @Override
    public UserDTO registerNewUser(CreateUser user) throws EmailAlReady, UserAlReady{
    
        Optional<User> exitingUserByMail = userRepository.findByEmail(user.getEmail());
        if(exitingUserByMail.isPresent()) {
            throw new EmailAlReady();
        }
            
        Optional<User> exitingUserByUsername = userRepository.findByUsername(user.getUsername());
        if(exitingUserByUsername.isPresent()) {
            throw new UserAlReady();
        }

...
...

    }

706111 dedi:

Email ve username'e sahip olan hesapların kontrolünü yapıyordum;

Java:Panoya kopyala

    @Override
    public UserDTO registerNewUser(CreateUser user) throws EmailAlReady, UserAlReady{
  
        Optional<User> exitingUserByMail = userRepository.findByEmail(user.getEmail());
        if(exitingUserByMail.isPresent()) {
            throw new EmailAlReady();
        }
          
        Optional<User> exitingUserByUsername = userRepository.findByUsername(user.getUsername());
        if(exitingUserByUsername.isPresent()) {
            throw new UserAlReady();
        }

...
...

    }

Ancak bu kadar oldu.

Genişletmek için tıkla...