Utilizza per facoltativo

Avendo usato Java 8 per circa 6 mesi circa, sono abbastanza contento delle nuove modifiche all'API. Un'area in cui non mi fido ancora è quando usare Optional. Mi sembra di oscillare tra il voler usarlo ovunque possa essere qualcosa nulle da nessuna parte.

Sembrano esserci molte situazioni in cui potrei usarlo, e non sono mai sicuro che aggiunga benefici (leggibilità / sicurezza nulla) o causi solo costi aggiuntivi.

Quindi, ho alcuni esempi e sarei interessato ai pensieri della comunità sul fatto che Optionalsia utile.

1 - Come metodo di restituzione del metodo pubblico quando il metodo potrebbe restituire null:

public Optional<Foo> findFoo(String id);

2 - Come parametro del metodo quando il parametro può essere null:

public Foo doSomething(String id, Optional<Bar> barOptional);

3 - Come membro facoltativo di un bean:

public class Book {

  private List<Pages> pages;
  private Optional<Index> index;

}

4 - In Collections:

In generale non penso:

List<Optional<Foo>>

aggiunge qualcosa, specialmente dal momento che si può usare filter()per rimuovere nullvalori ecc., ma ci sono degli usi utili Optionalnelle raccolte?

Qualche caso che ho perso?

Il punto principale di Optionalè fornire un mezzo per una funzione che restituisce un valore per indicare l'assenza di un valore di ritorno. Vedere questa discussione . Ciò consente al chiamante di continuare una catena di chiamate di metodo fluente.

Ciò corrisponde maggiormente al caso d'uso n. 1 nella domanda del PO. Tuttavia, l' assenza di un valore è una formulazione più precisa di null poiché qualcosa del genere IntStream.findFirstnon potrebbe mai restituire null.

Per il caso d'uso n. 2 , passando un argomento facoltativo a un metodo, questo potrebbe essere fatto funzionare, ma è piuttosto goffo. Supponiamo di avere un metodo che accetta una stringa seguita da una seconda stringa opzionale. Accettare un Optionalsecondo arg comporterebbe un codice come questo:

foo("bar", Optional.of("baz"));
foo("bar", Optional.empty());

Anche accettare null è più bello:

foo("bar", "baz");
foo("bar", null);

Probabilmente il migliore è avere un metodo sovraccarico che accetta un singolo argomento stringa e fornisce un valore predefinito per il secondo:

foo("bar", "baz");
foo("bar");

Questo ha dei limiti, ma è molto più bello di uno dei precedenti.

I casi d'uso n. 3 e n. 4 , con un Optionalcampo in una classe o in una struttura di dati, sono considerati un uso improprio dell'API. In primo luogo, va contro l'obiettivo di progettazione principale di Optionalcome indicato nella parte superiore. Secondo, non aggiunge alcun valore.

Esistono tre modi per gestire l'assenza di un valore in un Optional: fornire un valore sostitutivo, chiamare una funzione per fornire un valore sostitutivo o generare un'eccezione. Se stai memorizzando in un campo, lo faresti al momento dell'inizializzazione o dell'assegnazione. Se si aggiungono valori in un elenco, come menzionato nel PO, si ha la possibilità di aggiungere semplicemente il valore, "appiattendo" quindi i valori assenti.

Sono sicuro che qualcuno potrebbe escogitare alcuni casi inventati in cui vogliono davvero archiviare un Optionalcampo o una collezione, ma in generale, è meglio evitare di farlo.

Sono in ritardo al gioco, ma per quello che vale, voglio aggiungere i miei 2 centesimi. Sono contrari all'obiettivo progettuale diOptional , che è ben riassunto dalla risposta di Stuart Marks , ma sono ancora convinto della loro validità (ovviamente).

Usa facoltativo ovunque

In generale

Ho scritto un intero post sul blog sull'utilizzo,Optional ma sostanzialmente si riduce a questo:

• progettare le lezioni per evitare opzionalità ove possibile
• in tutti i restanti casi, l'impostazione predefinita dovrebbe essere quella di utilizzare Optionalinvece dinull
• eventualmente fare eccezioni per:
  • variabili locali
  • restituisce valori e argomenti a metodi privati
  • blocchi di codice critici per le prestazioni (nessuna ipotesi, utilizzare un profiler)

Le prime due eccezioni possono ridurre il sovraccarico percepito dei riferimenti a capo e a capo Optional . Sono scelti in modo tale che un null non possa mai legalmente passare un confine da un'istanza all'altra.

Si noti che ciò non consentirà quasi mai di accedere Optionalalle raccolte, il che è quasi negativo quanto le null. Basta non farlo. ;)

Per quanto riguarda le tue domande

1. Sì.
2. Se il sovraccarico non è un'opzione, sì.
3. Se altri approcci (sottoclasse, decorazione, ...) non sono un'opzione, sì.
4. Per favore no!

vantaggi

In questo modo si riduce la presenza di nulls nella base di codice, sebbene non li sradichi. Ma questo non è nemmeno il punto principale. Ci sono altri importanti vantaggi:

Chiarisce l'intento

utilizzando Optional indica chiaramente che la variabile è, beh, facoltativa. Qualsiasi lettore del tuo codice o consumatore della tua API sarà picchiato in testa per il fatto che potrebbe non esserci nulla e che è necessario un controllo prima di accedere al valore.

Rimuove l'incertezza

Senza Optionalil significato di un nullevento non è chiaro. Potrebbe essere una rappresentazione legale di uno stato (vedi Map.get) o un errore di implementazione come un'inizializzazione mancante o non riuscita.

Questo cambia radicalmente con l'uso persistente di Optional. Qui, già l'occorrenza di nullsignifica la presenza di un bug. (Perché se il valore fosse lasciato mancare, ne Optionalsarebbe stato usato uno.) Questo rende molto più semplice il debug di un'eccezione puntatore null poiché la domanda sul significato di questo nullè già stata risolta.

Più controlli null

Ora che nulla può nullpiù essere , questo può essere applicato ovunque. Sia con annotazioni, asserzioni o semplici verifiche, non devi mai pensare se questo argomento o quel tipo di ritorno possono essere nulli. Non può!

svantaggi

Certo, non esiste un proiettile d'argento ...

Prestazione

L'avvolgimento di valori (soprattutto primitivi) in un'istanza aggiuntiva può ridurre le prestazioni. In anelli stretti questo potrebbe diventare evidente o anche peggio.

Si noti che il compilatore potrebbe essere in grado di aggirare il riferimento aggiuntivo per le brevi vite di Optionals. In Java 10 tipi di valore potrebbero ulteriormente ridurre o rimuovere la penalità.

serializzazione

Optionalnon è serializzabile ma una soluzione alternativa non è eccessivamente complicata.

invarianza

A causa dell'invarianza dei tipi generici in Java, alcune operazioni diventano ingombranti quando il tipo di valore effettivo viene inserito in un argomento di tipo generico. Qui viene fornito un esempio (vedi "Polimorfismo parametrico") .

Personalmente, preferisco usare lo strumento di ispezione del codice di IntelliJ per utilizzare @NotNulle @Nullablecontrollare poiché si tratta in gran parte di tempo di compilazione (può avere alcuni controlli di runtime). Questo ha un sovraccarico inferiore in termini di leggibilità del codice e prestazioni di runtime. Non è rigoroso come l'utilizzo di Opzionale, tuttavia questa mancanza di rigore dovrebbe essere supportata da test unitari decenti.

public @Nullable Foo findFoo(@NotNull String id);

public @NotNull Foo doSomething(@NotNull String id, @Nullable Bar barOptional);

public class Book {

  private List<Pages> pages;
  private @Nullable Index index;

}

List<@Nullable Foo> list = ..

Funziona con Java 5 e non è necessario avvolgere e scartare i valori. (o creare oggetti wrapper)

Penso che Guava Optional e la loro pagina wiki lo mettano abbastanza bene:

Oltre all'aumento della leggibilità che deriva dal dare a null un nome, il più grande vantaggio di Optional è la sua resistenza agli idioti. Ti costringe a pensare attivamente al caso assente se vuoi che il tuo programma si compili del tutto, dal momento che devi scartare attivamente l'Opzionale e affrontare quel caso. Null semplifica in modo inquietante la semplice dimenticanza delle cose e, sebbene FindBugs sia di aiuto, non pensiamo che risolva anche il problema.

Ciò è particolarmente rilevante quando si restituiscono valori che possono o meno essere "presenti". Tu (e altri) avete molte più probabilità di dimenticare che other.method (a, b) potrebbe restituire un valore nullo di quanto probabilmente dimenticherete che a potrebbe essere nullo durante l'implementazione di other.method. La restituzione di Facoltativo rende impossibile per i chiamanti dimenticare quel caso, poiché devono scartare l'oggetto per la compilazione del proprio codice. - (Fonte: Guava Wiki - Usare ed evitare null - Qual è il punto? )

Optionalaggiunge un certo sovraccarico, ma penso che il suo chiaro vantaggio sia quello di rendere esplicito che un oggetto potrebbe essere assente e impone ai programmatori di gestire la situazione. Impedisce che qualcuno dimentichi l'amato != nullassegno.

Prendendo l'esempio di 2 , penso che sia molto più esplicito scrivere codice:

if(soundcard.isPresent()){
  System.out.println(soundcard.get());
}

di

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

Per me, il Optional meglio cattura il fatto che non è presente alcuna scheda audio.

I miei 2 ¢ sui tuoi punti:

1. public Optional<Foo> findFoo(String id);- Non sono sicuro di questo. Forse vorrei restituire un Result<Foo>che potrebbe essere vuoto o contenere un Foo. È un concetto simile, ma non proprioOptional .
2. public Foo doSomething(String id, Optional<Bar> barOptional);- Preferirei @Nullable e un controllo di ricerca, come nella risposta di Peter Lawrey - vedi anche questa discussione .
3. Il tuo esempio di libro - Non sono sicuro che utilizzerei l'Opzionale internamente, ciò potrebbe dipendere dalla complessità. Per l '"API" di un libro, userei unOptional<Index> getIndex() per indicare esplicitamente che il libro potrebbe non avere un indice.
4. Non lo userei nelle raccolte, piuttosto non consentire valori nulli nelle raccolte

In generale, proverei a ridurre al minimo il passaggio di nulls. (Una volta bruciato ...) Penso che valga la pena trovare le astrazioni appropriate e indicare ai colleghi programmatori ciò che rappresenta effettivamente un determinato valore di ritorno.

Dal tutorial Oracle :

Lo scopo di Opzionale non è quello di sostituire ogni singolo riferimento null nella base di codici, ma piuttosto di aiutare a progettare API migliori in cui, semplicemente leggendo la firma di un metodo, gli utenti possono dire se aspettarsi un valore opzionale. Inoltre, Opzionale ti costringe a scartare attivamente un Opzionale per affrontare l'assenza di un valore; di conseguenza, si protegge il codice da eccezioni di puntatore null non intenzionali.

1 - Come metodo di restituzione del metodo pubblico quando il metodo potrebbe restituire null:

Ecco un buon articolo che mostra l'utilità dell'usecase n. 1. Ecco questo codice

...
if (user != null) {
    Address address = user.getAddress();
    if (address != null) {
        Country country = address.getCountry();
        if (country != null) {
            String isocode = country.getIsocode();
            isocode = isocode.toUpperCase();
        }
    }
}
...

si trasforma in questo

String result = Optional.ofNullable(user)
  .flatMap(User::getAddress)
  .flatMap(Address::getCountry)
  .map(Country::getIsocode)
  .orElse("default");

usando Opzionale come valore di ritorno dei rispettivi metodi getter .

Ecco un uso interessante (credo) per ... Test.

Ho intenzione di testare pesantemente uno dei miei progetti e quindi costruisco affermazioni; solo ci sono cose che devo verificare e altre no.

Costruisco quindi cose da affermare e utilizzo un'asserzione per verificarle, in questo modo:

public final class NodeDescriptor<V>
{
    private final Optional<String> label;
    private final List<NodeDescriptor<V>> children;

    private NodeDescriptor(final Builder<V> builder)
    {
        label = Optional.fromNullable(builder.label);
        final ImmutableList.Builder<NodeDescriptor<V>> listBuilder
            = ImmutableList.builder();
        for (final Builder<V> element: builder.children)
            listBuilder.add(element.build());
        children = listBuilder.build();
    }

    public static <E> Builder<E> newBuilder()
    {
        return new Builder<E>();
    }

    public void verify(@Nonnull final Node<V> node)
    {
        final NodeAssert<V> nodeAssert = new NodeAssert<V>(node);
        nodeAssert.hasLabel(label);
    }

    public static final class Builder<V>
    {
        private String label;
        private final List<Builder<V>> children = Lists.newArrayList();

        private Builder()
        {
        }

        public Builder<V> withLabel(@Nonnull final String label)
        {
            this.label = Preconditions.checkNotNull(label);
            return this;
        }

        public Builder<V> withChildNode(@Nonnull final Builder<V> child)
        {
            Preconditions.checkNotNull(child);
            children.add(child);
            return this;
        }

        public NodeDescriptor<V> build()
        {
            return new NodeDescriptor<V>(this);
        }
    }
}

Nella classe NodeAssert, faccio questo:

public final class NodeAssert<V>
    extends AbstractAssert<NodeAssert<V>, Node<V>>
{
    NodeAssert(final Node<V> actual)
    {
        super(Preconditions.checkNotNull(actual), NodeAssert.class);
    }

    private NodeAssert<V> hasLabel(final String label)
    {
        final String thisLabel = actual.getLabel();
        assertThat(thisLabel).overridingErrorMessage(
            "node's label is null! I didn't expect it to be"
        ).isNotNull();
        assertThat(thisLabel).overridingErrorMessage(
            "node's label is not what was expected!\n"
            + "Expected: '%s'\nActual  : '%s'\n", label, thisLabel
        ).isEqualTo(label);
        return this;
    }

    NodeAssert<V> hasLabel(@Nonnull final Optional<String> label)
    {
        return label.isPresent() ? hasLabel(label.get()) : this;
    }
}

Il che significa che l'asserzione si innesca davvero solo se voglio controllare l'etichetta!

Optionalclass ti consente di evitare di usare nulle fornire un'alternativa migliore:

• Questo incoraggia lo sviluppatore a verificare la presenza al fine di evitare quelli non rilevati NullPointerException.

• L'API diventa meglio documentata perché è possibile vedere dove aspettarsi i valori che possono essere assenti.

Optionalfornisce una comoda API per ulteriori lavori con l'oggetto isPresent():; get(); orElse(); orElseGet(); orElseThrow(); map(); filter(); flatmap().

Inoltre, molti framework utilizzano attivamente questo tipo di dati e lo restituiscono dalla loro API.

In java, semplicemente non usarli a meno che tu non sia dipendente dalla programmazione funzionale.

Non hanno posto come argomenti di metodo (suppongo che qualcuno un giorno ti passerà un null opzionale, non solo un opzionale vuoto).

Hanno senso per i valori di ritorno, ma invitano la classe client a continuare a estendere la catena di costruzione del comportamento.

FP e catene hanno poco spazio in un linguaggio imperativo come Java perché rende molto difficile il debug, non solo la lettura. Quando passi alla linea, non puoi conoscere lo stato né l'intenzione del programma; devi entrare per capirlo (nel codice che spesso non è tuo e molti frame di stack in profondità nonostante i filtri di step) e devi aggiungere molti punti di interruzione per assicurarti che possa fermarsi nel codice / lambda che hai aggiunto, invece di camminare semplicemente sulle linee banali if / else / call.

Se vuoi una programmazione funzionale, scegli qualcosa di diverso da Java e spera di avere gli strumenti per il debug.

Non penso che Opzionale sia un sostituto generale per i metodi che potenzialmente restituiscono valori null.

L'idea di base è: l'assenza di un valore non significa che potenzialmente sia disponibile in futuro. È una differenza tra findById (-1) e findById (67).

Le informazioni principali di Optionals per il chiamante sono che potrebbe non contare sul valore fornito, ma potrebbe essere disponibile in un determinato momento. Forse scomparirà di nuovo e tornerà più tardi ancora una volta. È come un interruttore on / off. Hai la "opzione" per accendere o spegnere la luce. Ma non hai alcuna opzione se non hai una luce per accendere.

Quindi trovo troppo disordinato introdurre Optionals ovunque dove in precedenza era potenzialmente restituito null. Userò ancora null, ma solo in aree riservate come la radice di un albero, l'inizializzazione pigra e i metodi di ricerca espliciti.

Sembra Optionalè utile solo se il tipo T in opzionale è un tipo primitivo come int, long, char, ecc Per le classi di "veri", non ha senso per me, come è possibile utilizzare unnull valore comunque.

Penso che sia stato preso da qui (o da un altro concetto di linguaggio simile).

Nullable<T>

In C # questo è Nullable<T>stato introdotto molto tempo fa per avvolgere i tipi di valore.

An ha una semantica simile a un'istanza non modificabile del modello di progettazione Iterator :Optional

• potrebbe o meno riferirsi a un oggetto (come indicato da isPresent() )
• può essere dereferenziato (usando get() ) se fa riferimento a un oggetto
• ma non può essere portato alla posizione successiva nella sequenza (non ha alcun next()metodo).

Pertanto, considera di restituire o passare un Optionalcontesto in cui potresti aver precedentemente considerato l'utilizzo di un Java Iterator.

Java SE 8 introduce una nuova classe chiamata java.util.Optional,

È possibile creare un facoltativo vuoto o facoltativo con valore null.

Optional<String> emptyOptional = Optional.empty(); 

Ed ecco un opzionale con un valore non nullo:

String valueString = new String("TEST");
Optional<String> optinalValueString = Optional.of(valueString );

Fai qualcosa se è presente un valore

Ora che hai un oggetto opzionale, puoi accedere ai metodi disponibili per gestire esplicitamente la presenza o l'assenza di valori. Invece di dover ricordare di fare un controllo nullo, come segue:

String nullString = null;
if (nullString != null) {
    System.out.println(nullString);
}

È possibile utilizzare il metodo ifPresent (), come segue:

Optional<String> optinalString= null;
optinalString.ifPresent(System.out::println);

package optinalTest;

import java.util.Optional;

public class OptionalTest {
    public Optional<String> getOptionalNullString() {
        return null;
//      return Optional.of("TESt");
    }

    public static void main(String[] args) {

        OptionalTest optionalTest = new OptionalTest();

        Optional<Optional<String>> optionalNullString = Optional.ofNullable(optionalTest.getOptionalNullString());

        if (optionalNullString.isPresent()) {
            System.out.println(optionalNullString.get());
        }
    }
}