Perché utilizzare Opzionale in Java 8+ anziché i tradizionali controlli puntatore null?

Di recente ci siamo trasferiti su Java 8. Ora vedo le applicazioni inondate di Optionaloggetti.

Prima di Java 8 (stile 1)

Employee employee = employeeServive.getEmployee();

if(employee!=null){
    System.out.println(employee.getId());
}

Dopo Java 8 (stile 2)

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employee = employeeOptional.get();
    System.out.println(employee.getId());
}

Non vedo alcun valore aggiunto di Optional<Employee> employeeOptional = employeeService.getEmployee();quando il servizio stesso ritorna facoltativo:

Provenendo da uno sfondo Java 6, vedo lo Stile 1 come più chiaro e con meno righe di codice. C'è qualche vero vantaggio che mi manca qui?

Consolidato dalla comprensione di tutte le risposte e ulteriori ricerche nel blog

Lo stile 2 non ha abbastanza Java 8 per vedere tutti i vantaggi. Non vuoi if ... useaffatto. Vedi gli esempi di Oracle . Seguendo i loro consigli, otteniamo:

Stile 3

// Changed EmployeeServive to return an optional, no more nulls!
Optional<Employee> employee = employeeServive.getEmployee();
employee.ifPresent(e -> System.out.println(e.getId()));

O uno snippet più lungo

Optional<Employee> employee = employeeServive.getEmployee();
// Sometimes an Employee has forgotten to write an up-to-date timesheet
Optional<Timesheet> timesheet = employee.flatMap(Employee::askForCurrentTimesheet); 
// We don't want to do the heavyweight action of creating a new estimate if it will just be discarded
client.bill(timesheet.orElseGet(EstimatedTimesheet::new));

Se stai usando Optionalun livello di "compatibilità" tra un'API precedente che potrebbe ancora restituire null, potrebbe essere utile creare l'Opzionale (non vuoto) nell'ultima fase per essere sicuro di avere qualcosa. Ad esempio, dove hai scritto:

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

Opterei per:

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

Il punto è che sai che esiste un servizio per i dipendenti non nullo , quindi puoi concludere questo Optionalcon un Optional.of(). Quindi, quando lo getEmployee()chiedi, potresti avere o meno un dipendente. Quel dipendente può (o possibilmente non avere) un documento d'identità. Quindi, se hai finito con un ID, vuoi stamparlo.

Non è necessario controllare esplicitamente eventuali null, presenza, ecc., In questo codice.

Non c'è quasi nessun valore aggiunto nell'avere un Optionalvalore singolo. Come hai visto, questo sostituisce solo un controllo per nullcon un controllo per presenza.

C'è un enorme valore aggiunto nell'avere una Collectiondi queste cose. Tutti i metodi di streaming introdotti per sostituire i loop di basso livello vecchio stile comprendono le Optionalcose e fanno le cose giuste su di esse (non elaborandole o alla fine restituendo un altro non impostato Optional). Se hai a che fare con n oggetti più spesso che con singoli oggetti (e il 99% di tutti i programmi realistici lo fanno), è un enorme miglioramento avere il supporto integrato per le cose facoltativamente presenti. Nel caso ideale non devi mai controllare null o presenza.

Finché usi Optionalesattamente come un'API di fantasia isNotNull(), quindi sì, non troverai differenze con il solo controllo di null.

Le cose non si dovrebbe usare Optionalper

Usare Optionalsolo per verificare la presenza di un valore è Bad Code ™:

// BAD CODE ™ --  just check getEmployee() != null  
Optional<Employee> employeeOptional =  Optional.ofNullable(employeeService.getEmployee());  
if(employeeOptional.isPresent()) {  
    Employee employee = employeeOptional.get();  
    System.out.println(employee.getId());
}  

Cose che dovresti usare Optionalper

Evitare che un valore non sia presente, producendo uno quando necessario quando si utilizzano metodi API con ritorno null:

Employee employee = Optional.ofNullable(employeeService.getEmployee())
                            .orElseGet(Employee::new);
System.out.println(employee.getId());

Oppure, se la creazione di un nuovo dipendente è troppo costosa:

Optional<Employee> employee = Optional.ofNullable(employeeService.getEmployee());
System.out.println(employee.map(Employee::getId).orElse("No employee found"));

Inoltre, rendere tutti consapevoli che i propri metodi potrebbero non restituire un valore (se, per qualsiasi motivo, non è possibile restituire un valore predefinito come sopra):

// Your code without Optional
public Employee getEmployee() {
    return someCondition ? null : someEmployee;
}
// Someone else's code
Employee employee = getEmployee(); // compiler doesn't complain
// employee.get...() -> NPE awaiting to happen, devs criticizing your code

// Your code with Optional
public Optional<Employee> getEmployee() {
    return someCondition ? Optional.empty() : Optional.of(someEmployee);
}
// Someone else's code
Employee employee = getEmployee(); // compiler complains about incompatible types
// Now devs either declare Optional<Employee>, or just do employee = getEmployee().get(), but do so consciously -- not your fault.

E infine, ci sono tutti i metodi simili a stream che sono già stati spiegati in altre risposte, anche se quelli non sono proprio tu che decidi di utilizzare Optionalma facendo uso di quelli Optionalforniti da qualcun altro.

Il punto chiave per me nell'utilizzo di Facoltativo è di chiarire quando lo sviluppatore deve verificare se la funzione restituisce valore o meno.

//service 1
Optional<Employee> employeeOptional = employeeService.getEmployee();
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

//service 2
Employee employee = employeeService.getEmployeeXTPO();
System.out.println(employee.getId());

Il tuo errore principale è che stai ancora pensando in termini più procedurali. Questo non è inteso come una critica a te come persona, è semplicemente un'osservazione. Pensare in termini più funzionali arriva con il tempo e la pratica, e quindi i metodi sonoPresent e sembrano le cose più ovvie e corrette da chiamare per te. Il tuo errore secondario secondario sta creando l'Opzionale all'interno del tuo metodo. L'opzionale ha lo scopo di aiutare a documentare che qualcosa può o meno restituire un valore. Non potresti ottenere nulla.

Questo ti ha portato a scrivere un codice perfettamente leggibile che sembra perfettamente ragionevole, ma sei stato sedotto dai vili tentatori gemelli che ottengono ed èPresente.

Naturalmente la domanda diventa rapidamente "perché isPresent e arriva anche lì?"

Una cosa che molte persone qui mancano è che isPresent () è che non è qualcosa che è fatto per il nuovo codice scritto da persone completamente a bordo con come sono le lambda dannatamente utili e a chi piace la cosa funzionale.

Tuttavia, ci offre alcuni (due) buoni, fantastici, glamour (?) Vantaggi:

• Facilita la transizione del codice legacy per utilizzare le nuove funzionalità.
• Facilita le curve di apprendimento di Opzionale.

Il primo è piuttosto semplice.

Immagina di avere un'API simile a questa:

public interface SnickersCounter {
  /** 
   * Provides a proper count of how many snickers have been consumed in total.
   */
  public SnickersCount howManySnickersHaveBeenEaten();

  /**
    * returns the last snickers eaten.<br>
    * If no snickers have been eaten null is returned for contrived reasons.
    */
  public Snickers lastConsumedSnickers();
}

E hai avuto una classe legacy usando questo come tale (riempi gli spazi):

Snickers lastSnickers = snickersCounter.lastConsumedSnickers();
if(null == lastSnickers) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers);
}

Un esempio inventato per essere sicuro. Ma abbi pazienza qui.

Java 8 è stato lanciato e stiamo cercando di salire a bordo. Quindi una delle cose che facciamo è che vogliamo sostituire la nostra vecchia interfaccia con qualcosa che renda Opzionale. Perché? Perché come qualcun altro ha già gentilmente citato: questo elimina le congetture sul fatto che qualcosa possa essere nullo. Questo è già stato sottolineato da altri. Ma ora abbiamo un problema. Immagina di avere (mi scusi mentre premo alt + F7 su un metodo innocente), 46 posti in cui questo metodo viene chiamato in un codice legacy ben testato che fa un lavoro eccellente altrimenti. Ora devi aggiornare tutti questi.

QUESTO è dove brilla isPresent.

Perché ora: Snickers lastSnickers = snickersCounter.lastConsumedSnickers (); if (null == lastSnickers) {throw new NoSuchSnickersException (); } else {consumer.giveDiabetes (lastSnickers); }

diventa:

Optional<Snickers> lastSnickers = snickersCounter.lastConsumedSnickers();
if(!lastSnickers.isPresent()) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers.get());
}

E questo è un semplice cambiamento che puoi dare al nuovo junior: può fare qualcosa di utile e esplorerà la base di codice allo stesso tempo. win-win. Dopotutto, qualcosa di simile a questo modello è piuttosto diffuso. E ora non devi riscrivere il codice per usare lambdas o altro. (In questo caso particolare sarebbe banale, ma lascio pensare a esempi in cui sarebbe difficile come esercizio per il lettore.)

Nota che ciò significa che il modo in cui lo hai fatto è essenzialmente un modo per gestire il codice legacy senza effettuare costose riscritture. E il nuovo codice?

Bene, nel tuo caso, dove vuoi solo stampare qualcosa, dovresti semplicemente fare:

. SnickersCounter.lastConsumedSnickers () ifPresent (System.out :: println);

Che è piuttosto semplice e perfettamente chiaro. Il punto che gorgoglia lentamente verso la superficie, quindi, è che esistono casi d'uso per get () e isPresent (). Sono lì per permetterti di modificare meccanicamente il codice esistente per utilizzare i tipi più recenti senza pensarci troppo. Ciò che stai facendo è quindi errato nei seguenti modi:

• Stai chiamando un metodo che potrebbe restituire null. L'idea corretta sarebbe che il metodo restituisca null.
• Stai usando i metodi legid legacy per gestire questo opzionale, invece di usare i nuovi gustosi metodi che contengono fantasia di lambda.

Se si desidera utilizzare Opzionale come semplice controllo di sicurezza null, ciò che si dovrebbe fare è semplicemente questo:

new Optional.ofNullable(employeeServive.getEmployee())
    .map(Employee::getId)
    .ifPresent(System.out::println);

Naturalmente, la bella versione di questo sembra:

employeeService.getEmployee()
    .map(Employee::getId)
    .ifPresent(System.out::println);

A proposito, anche se non è assolutamente necessario, ti consiglio di utilizzare una nuova riga per operazione, in modo che sia più facile da leggere. Facile da leggere e comprendere batte la concisione in qualsiasi giorno della settimana.

Questo è ovviamente un esempio molto semplice in cui è facile capire tutto ciò che stiamo cercando di fare. Non è sempre così semplice nella vita reale. Ma nota come in questo esempio, ciò che stiamo esprimendo sono le nostre intenzioni. Vogliamo ottenere il dipendente, ottenere il suo documento d'identità e, se possibile, stamparlo. Questa è la seconda grande vittoria con Opzionale. Ci consente di creare un codice più chiaro. Penso anche che fare cose come fare un metodo che faccia un sacco di cose in modo da poterlo alimentare su una mappa è in generale una buona idea.

Non vedo alcun vantaggio nello stile 2. Devi ancora capire che hai bisogno del controllo null e ora è ancora più grande, quindi meno leggibile.

Lo stile migliore sarebbe, se employeeServive.getEmployee () restituirebbe Opzionale e il codice diventerebbe:

Optional<Employee> employeeOptional = employeeServive.getEmployee();
if(employeeOptional.isPresent()){
    Employee employee= employeeOptional.get();
    System.out.println(employee.getId());
}

In questo modo non puoi callemployeeServive.getEmployee (). GetId () e noti che dovresti gestire il valore facoltativo in qualche modo. E se nel tuo intero codebase i metodi non restituiscono mai null (o quasi mai con eccezioni ben note al tuo team a questa regola), aumenterà la sicurezza contro NPE.

Credo che il più grande vantaggio è che se la vostra firma metodo restituisce un Employeevoi non controllare per nulla. Sai con quella firma che è garantito per restituire un dipendente. Non è necessario gestire un caso di errore. Con un optional sai che lo fai.

Nel codice che ho visto ci sono controlli null che non falliranno mai poiché le persone non vogliono tracciare il codice per determinare se un null è possibile, quindi lanciano controlli null ovunque in modo difensivo. Questo rende il codice un po 'più lento, ma soprattutto rende il codice molto più rumoroso.

Tuttavia, affinché funzioni, è necessario applicare questo modello in modo coerente.

La mia risposta è: basta. Almeno pensaci due volte se è davvero un miglioramento.

Un'espressione (presa da un'altra risposta) come

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

sembra essere il giusto modo funzionale di trattare con metodi di ritorno originariamente nulli. Sembra bello, non getta mai e non ti fa mai pensare a maneggiare il caso "assente".

Sembra meglio del vecchio stile

Employee employee = employeeService.getEmployee();
if (employee != null) {
    ID id = employee.getId();
    if (id != null) {
        System.out.println(id);
    }
}

il che rende evidente che potrebbero esserci delle elseclausole.

Lo stile funzionale

• sembra completamente diverso (ed è illeggibile per le persone non utilizzate)
• è un dolore per il debug
• non può essere facilmente esteso per gestire il caso "assente" ( orElsenon è sempre sufficiente)
• induce in errore a ignorare il caso "assente"

In nessun caso dovrebbe essere usato come una panacea. Se fosse universalmente applicabile, la semantica .dell'operatore dovrebbe essere sostituita dalla semantica ?.dell'operatore , l'NPE dimenticato e tutti i problemi ignorati.

Pur essendo un grande fan di Java, devo dire che lo stile funzionale è solo un sostituto della dichiarazione di un povero Java

employeeService
.getEmployee()
?.getId()
?.apply(id => System.out.println(id));

ben noto da altre lingue. Siamo d'accordo che questa affermazione

• non è (davvero) funzionale?
• è molto simile al codice vecchio stile, solo molto più semplice?
• è molto più leggibile dello stile funzionale?
• è il debugger-friendly?

Opzionale è un concetto (un tipo di ordine superiore) proveniente dalla programmazione funzionale. Usarlo elimina il controllo nidificato nidificato e ti salva dalla piramide del destino.