Perché Java 8's Optional non dovrebbe essere usato negli argomenti

Ho letto su molti siti Web. Opzionale dovrebbe essere usato solo come tipo restituito e non usato negli argomenti del metodo. Sto lottando per trovare una ragione logica per cui. Ad esempio ho un pezzo di logica che ha 2 parametri opzionali. Quindi penso che avrebbe senso scrivere la mia firma del metodo in questo modo (soluzione 1):

public int calculateSomething(Optional<String> p1, Optional<BigDecimal> p2 {
    // my logic
}

Molte pagine Web specificano Opzionale non devono essere utilizzate come argomenti del metodo. Con questo in mente, potrei usare la seguente firma del metodo e aggiungere un commento Javadoc chiaro per specificare che gli argomenti possono essere nulli, sperando che i futuri manutentori leggano il Javadoc e quindi eseguano sempre controlli nulli prima di utilizzare gli argomenti (soluzione 2) :

public int calculateSomething(String p1, BigDecimal p2) {
    // my logic
}

In alternativa, potrei sostituire il mio metodo con quattro metodi pubblici per fornire un'interfaccia più gradevole e rendere più ovvio p1 e p2 opzionali (soluzione 3):

public int calculateSomething() {
    calculateSomething(null, null);
}

public int calculateSomething(String p1) {
    calculateSomething(p1, null);
}

public int calculateSomething(BigDecimal p2) {
    calculateSomething(null, p2);
}

public int calculateSomething(String p1, BigDecimal p2) {
    // my logic
}

Ora provo a scrivere il codice della classe che invoca questo pezzo di logica per ogni approccio. Richiamo prima i due parametri di input da un altro oggetto che restituisce se Optionalpoi invococalculateSomething . Pertanto, se viene utilizzata la soluzione 1, il codice chiamante sarà simile al seguente:

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1, p2);

se viene utilizzata la soluzione 2, il codice chiamante sarà simile al seguente:

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1.orElse(null), p2.orElse(null));

se viene applicata la soluzione 3, potrei usare il codice sopra o potrei usare il seguente (ma è significativamente più codice):

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result;
if (p1.isPresent()) {
    if (p2.isPresent()) {
        result = myObject.calculateSomething(p1, p2);
    } else {
        result = myObject.calculateSomething(p1);
    }
} else {
    if (p2.isPresent()) {
        result = myObject.calculateSomething(p2);
    } else {
        result = myObject.calculateSomething();
    }
}

Quindi la mia domanda è: perché è considerata una cattiva pratica usare Optionals come argomenti del metodo (vedi soluzione 1)? Mi sembra la soluzione più leggibile e rende più evidente che i parametri potrebbero essere vuoti / nulli per i futuri manutentori. (Sono consapevole che i progettisti Optionalintendevano utilizzarlo solo come tipo restituito, ma non riesco a trovare alcun motivo logico per non utilizzarlo in questo scenario).

Oh, quegli stili di codifica devono essere presi con un po 'di sale.

1. (+) Passare un risultato Opzionale a un altro metodo, senza alcuna analisi semantica; lasciandolo al metodo, va bene.
2. (-) L'uso di parametri opzionali che causano la logica condizionale all'interno dei metodi è letteralmente controproducente.
3. (-) La necessità di comprimere un argomento in un facoltativo, non è ottimale per il compilatore ed esegue un wrapping non necessario.
4. (-) Rispetto ai parametri nullable Opzionale è più costoso.

In generale: Opzionale unifica due stati, che devono essere svelati. Quindi più adatto per il risultato che per l'input, per la complessità del flusso di dati.

Il miglior post che ho visto sull'argomento è stato scritto da Daniel Olszewski :

Sebbene possa essere allettante considerare Opzionale per i parametri del metodo non obbligatori, una soluzione del genere impallidisce rispetto ad altre possibili alternative. Per illustrare il problema, esaminare la seguente dichiarazione del costruttore:

public SystemMessage(String title, String content, Optional<Attachment> attachment) {
    // assigning field values
}

A prima vista può sembrare una giusta decisione di progettazione. Dopotutto, abbiamo esplicitamente contrassegnato il parametro allegato come facoltativo. Tuttavia, per quanto riguarda la chiamata al costruttore, il codice client può diventare un po 'goffo.

SystemMessage withoutAttachment = new SystemMessage("title", "content", Optional.empty());
Attachment attachment = new Attachment();
SystemMessage withAttachment = new SystemMessage("title", "content", Optional.ofNullable(attachment));

Invece di fornire chiarezza, i metodi di fabbrica della classe Optional distraggono solo il lettore. Nota che c'è solo un parametro opzionale, ma immagina di averne due o tre. Lo zio Bob non sarebbe sicuramente orgoglioso di tale codice 😉

Quando un metodo può accettare parametri opzionali, è preferibile adottare l'approccio ben collaudato e progettare tale caso utilizzando il metodo di sovraccarico. Nell'esempio della classe SystemMessage, la dichiarazione di due costruttori separati è superiore all'utilizzo di Opzionale.

public SystemMessage(String title, String content) {
    this(title, content, null);
}

public SystemMessage(String title, String content, Attachment attachment) {
    // assigning field values
}

Questa modifica rende il codice client molto più semplice e facile da leggere.

SystemMessage withoutAttachment = new SystemMessage("title", "content");
Attachment attachment = new Attachment();
SystemMessage withAttachment = new SystemMessage("title", "content", attachment);

Non ci sono quasi buoni motivi per non utilizzare Optionalcome parametri. Gli argomenti contro questo si basano su argomenti dell'autorità (vedi Brian Goetz - il suo argomento è che non possiamo far valere opzioni non nulle) o che gli Optionalargomenti possono essere nulli (essenzialmente lo stesso argomento). Naturalmente, qualsiasi riferimento in Java può essere nullo, dobbiamo incoraggiare le regole imposte dal compilatore, non la memoria dei programmatori (il che è problematico e non scalabile).

I linguaggi di programmazione funzionale incoraggiano i Optionalparametri. Uno dei modi migliori per utilizzarlo è disporre di più parametri opzionali e utilizzare liftM2per utilizzare una funzione presupponendo che i parametri non siano vuoti e restituire un facoltativo (vedere http://www.functionaljava.org/javadoc/4.4/functionaljava/fj/ data / Option.html # liftM2-fj.F- ). Java 8 ha purtroppo implementato una libreria molto limitata con supporto opzionale.

Come programmatori Java dovremmo usare null solo per interagire con le librerie legacy.

Questo consiglio è una variante della regola empirica "essere il più aspecifico possibile riguardo agli input e il più specifico possibile riguardo agli output".

Di solito se si dispone di un metodo che accetta un valore semplice non nullo, è possibile mapparlo su Optional, quindi la versione normale è strettamente più non specifica per quanto riguarda gli input. Tuttavia, ci sono una serie di possibili ragioni per cui si vorrebbe richiedere un Optionalargomento:

• vuoi che la tua funzione sia usata insieme ad un'altra API che restituisce un Optional
• La tua funzione dovrebbe restituire qualcosa di diverso da uno vuoto Optionalse il valore dato è vuoto
• Pensi che Optionalsia così fantastico che a chiunque usi la tua API dovrebbe essere richiesto di conoscerlo ;-)

Il modello con Optionalè per evitare di tornare null . È ancora perfettamente possibile passare nulla un metodo.

Anche se questi non sono ancora ufficiali, puoi usare le annotazioni in stile JSR-308 per indicare se accetti o meno i nullvalori nella funzione. Tieni presente che dovresti avere gli strumenti giusti per identificarlo effettivamente e fornirebbe più di un controllo statico rispetto a una politica di runtime applicabile, ma sarebbe di aiuto.

public int calculateSomething(@NotNull final String p1, @NotNull final String p2) {}

Questo mi sembra un po 'sciocco, ma l'unica ragione a cui riesco a pensare è che gli argomenti degli oggetti nei parametri del metodo sono già opzionali in un certo senso: possono essere nulli. Pertanto forzare qualcuno a prendere un oggetto esistente e avvolgerlo in un optional è inutile.

Detto questo, concatenare insieme metodi che prendono / restituiscono opzioni è una cosa ragionevole da fare, ad es. Forse monade.

Dai un'occhiata a JavaDoc in JDK10, https://docs.oracle.com/javase/10/docs/api/java/util/Optional.html , viene aggiunta una nota API:

Nota API: facoltativo è principalmente destinato all'uso come tipo di restituzione del metodo in cui è chiaramente necessario rappresentare "nessun risultato" e dove è probabile che l'uso di null causi errori.

La mia opinione è che Opzionale dovrebbe essere una Monade e questi non sono concepibili in Java.

Nella programmazione funzionale hai a che fare con funzioni di ordine puro e superiore che accettano e compongono i loro argomenti solo in base al loro "tipo di dominio aziendale". La composizione di funzioni che si nutrono o il cui calcolo deve essere riferito al mondo reale (i cosiddetti effetti collaterali) richiede l'applicazione di funzioni che si occupano di decomprimere automaticamente i valori dalle monadi che rappresentano il mondo esterno (Stato, Configurazione, Futures, forse, entrambi, scrittore, ecc ...); questo si chiama sollevamento. Puoi pensarlo come una sorta di separazione delle preoccupazioni.

Mischiare questi due livelli di astrazione non facilita la leggibilità, quindi è meglio evitarlo.

Un altro motivo per essere cauti quando si passa un Optionalparametro as è che un metodo dovrebbe fare una cosa ... Se si passa un Optionalparametro si potrebbe preferire fare più di una cosa, potrebbe essere simile passare un parametro booleano.

public void method(Optional<MyClass> param) {
     if(param.isPresent()) {
         //do something
     } else {
         //do some other
     }
 }

L'accettazione di Opzionale come parametri provoca un avvolgimento non necessario a livello del chiamante.

Ad esempio nel caso di:

public int calculateSomething(Optional<String> p1, Optional<BigDecimal> p2 {}

Supponiamo di avere due stringhe non nulle (cioè restituite da un altro metodo):

String p1 = "p1"; 
String p2 = "p2";

Sei costretto a avvolgerli in Opzionale anche se sai che non sono vuoti.

Questo peggiora anche quando devi comporre con altre strutture "mappabili", ad es. Eithers :

Either<Error, String> value = compute().right().map((s) -> calculateSomething(
< here you have to wrap the parameter in a Optional even if you know it's a 
  string >));

ref:

i metodi non dovrebbero aspettarsi Opzione come parametri, questo è quasi sempre un odore di codice che indicava una perdita del flusso di controllo dal chiamante alla chiamata, dovrebbe essere responsabilità del chiamante controllare il contenuto di un'Opzione

rif. https://github.com/teamdigitale/digital-citizenship-functions/pull/148#discussion_r170862749

Penso che sia perché di solito scrivi le tue funzioni per manipolare i dati, e poi elevali Optionalall'utilizzo mape funzioni simili. Ciò aggiunge il Optionalcomportamento predefinito ad esso. Certo, potrebbero esserci casi in cui è necessario scrivere la propria funzione ausiliaria su cui funziona Optional.

Credo che la risposta dell'essere sia che devi prima verificare se Opzionale è nullo stesso e quindi provare a valutare il valore che avvolge. Troppe convalide non necessarie.

Gli optionals non sono progettati per questo scopo, come spiegato bene da Brian Goetz .

Puoi sempre usare @Nullable per indicare che un argomento del metodo può essere nullo. L'uso di un facoltativo non ti consente davvero di scrivere in modo più accurato la logica del tuo metodo.

Un altro approccio, quello che puoi fare è

// get your optionals first
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();

// bind values to a function
Supplier<Integer> calculatedValueSupplier = () -> { // your logic here using both optional as state}

Una volta che hai creato una funzione (fornitore in questo caso) sarai in grado di passarla come qualsiasi altra variabile e sarai in grado di chiamarla usando

calculatedValueSupplier.apply();

L'idea qui è se hai un valore facoltativo o meno sarà il dettaglio interno della tua funzione e non sarà nel parametro. Pensare funzioni quando si pensa all'opzionale come parametro è in realtà una tecnica molto utile che ho trovato.

Per quanto riguarda la tua domanda se dovresti effettivamente farlo o meno si basa sulle tue preferenze, ma come altri hanno detto che rende la tua API brutta a dir poco.

All'inizio, ho anche preferito passare gli Optionals come parametro, ma se passi da una prospettiva API-Designer a una prospettiva API-User, vedi gli svantaggi.

Per il tuo esempio, dove ogni parametro è facoltativo, suggerirei di cambiare il metodo di calcolo in una propria classe come segue:

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();

MyCalculator mc = new MyCalculator();
p1.map(mc::setP1);
p2.map(mc::setP2);
int result = mc.calculate();

So che questa domanda riguarda più l'opinione che i fatti concreti. Ma di recente sono passato dall'essere uno sviluppatore .net a uno java, quindi di recente mi sono unito alla festa opzionale. Inoltre, preferirei dichiararlo come commento, ma poiché il mio livello di punti non mi consente di commentare, sono costretto a inserire questo come risposta.

Quello che ho fatto, che mi ha servito bene come regola empirica. Utilizzare Optionals per i tipi di restituzione e utilizzare Optionals solo come parametri, se richiedo sia il valore dell'Opzionale, sia il tempo o meno l'Opzionale aveva un valore all'interno del metodo.

Se mi interessa solo il valore, controllo isPresent prima di chiamare il metodo, se ho un tipo di registrazione o logica diversa all'interno del metodo che dipende dall'esistenza del valore, allora passerò felicemente nell'Opzionale.

Questo perché abbiamo requisiti diversi per un utente API e uno sviluppatore API.

Uno sviluppatore è responsabile di fornire una specifica precisa e un'implementazione corretta. Pertanto, se lo sviluppatore è già a conoscenza del fatto che un argomento è facoltativo, l'implementazione deve gestirlo correttamente, sia esso nullo o facoltativo. L'API dovrebbe essere il più semplice possibile per l'utente e null è il più semplice.

D'altra parte, il risultato viene passato dallo sviluppatore API all'utente. Tuttavia, la specifica è completa e dettagliata, c'è ancora la possibilità che l'utente non ne sia consapevole o sia solo pigro a gestirla. In questo caso, il risultato facoltativo impone all'utente di scrivere del codice aggiuntivo per gestire un possibile risultato vuoto.

Prima di tutto, se stai usando il metodo 3, puoi sostituire quelle ultime 14 righe di codice con questo:

int result = myObject.calculateSomething(p1.orElse(null), p2.orElse(null));

Le quattro varianti che hai scritto sono metodi convenienti . Dovresti usarli solo quando sono più convenienti. Questo è anche l'approccio migliore. In questo modo, l'API è molto chiara su quali membri sono necessari e quali no. Se non si desidera scrivere quattro metodi, è possibile chiarire le cose in base al nome dei parametri:

public int calculateSomething(String p1OrNull, BigDecimal p2OrNull)

In questo modo, è chiaro che sono ammessi valori null.

Il tuo uso di p1.orElse(null)illustra quanto è dettagliato il nostro codice quando si utilizza Opzionale, il che è parte del motivo per cui lo evito. Opzionale è stato scritto per la programmazione funzionale. I flussi ne hanno bisogno. I tuoi metodi probabilmente non dovrebbero mai restituire Opzionale a meno che non sia necessario usarli nella programmazione funzionale. Esistono metodi, come il Optional.flatMap()metodo, che richiedono un riferimento a una funzione che restituisce Facoltativo. Ecco la sua firma:

public <U> Optional<U> flatMap(Function<? super T, ? extends Optional<? extends U>> mapper)

Quindi questa è di solito l'unica buona ragione per scrivere un metodo che ritorna Opzionale. Ma anche lì, può essere evitato. Puoi passare un getter che non restituisce Opzionale a un metodo come flatMap (), avvolgendolo in un altro metodo che converte la funzione nel tipo giusto. Il metodo wrapper è simile al seguente:

public static <T, U> Function<? super T, Optional<U>> optFun(Function<T, U> function) {
    return t -> Optional.ofNullable(function.apply(t));
}

Supponiamo quindi di avere un getter come questo: String getName()

Non puoi passarlo a flatMap in questo modo:

opt.flatMap(Widget::getName) // Won't work!

Ma puoi passarlo così:

opt.flatMap(optFun(Widget::getName)) // Works great!

Al di fuori della programmazione funzionale, gli Optionals dovrebbero essere evitati.

Brian Goetz l'ha detto meglio quando ha detto questo:

Il motivo per cui Opzionale è stato aggiunto a Java è perché questo:

return Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .findFirst()
    .getOrThrow(() -> new InternalError(...));

è più pulito di così:

Method matching =
    Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .getFirst();
if (matching == null)
  throw new InternalError("Enclosing method not found");
return matching;