Warum wird eine optionale Option verwendet, um die Variable auf Null zu prüfen?

Nehmen Sie die beiden Codebeispiele:

if(optional.isPresent()) {
    //do your thing
}

if(variable != null) {
    //do your thing
}

Soweit ich das beurteilen kann, besteht der offensichtlichste Unterschied darin, dass für das optionale Objekt ein zusätzliches Objekt erstellt werden muss.

Viele Menschen haben jedoch schnell begonnen, Optionals einzuführen. Was ist der Vorteil der Verwendung von Optionen gegenüber einer Nullprüfung?

Optionalnutzt das Typensystem für die Arbeit, die Sie sonst in Ihrem Kopf erledigen müssten: Erinnern Sie sich, ob eine bestimmte Referenz vorhanden ist oder nicht null. Das ist gut. Es ist immer klug, den Compiler mit langweiliger Drogenarbeit umgehen zu lassen und menschliche Gedanken für kreative, interessante Arbeit zu reservieren.

Ohne Optionalist jeder Verweis in Ihrem Code wie eine nicht explodierte Bombe. Der Zugriff darauf kann nützlich sein oder Ihr Programm mit einer Ausnahme beenden.

Mit Optional und ohne nullist jeder Zugriff auf eine normale Referenz erfolgreich, und jede Referenz auf eine Option ist erfolgreich, sofern sie nicht deaktiviert ist und Sie dies nicht überprüft haben. Das ist ein enormer Gewinn an Wartbarkeit.

Leider sind die meisten Sprachen, die jetzt angeboten Optionalwerden, nicht abgeschafft worden null. Sie können also nur von dem Konzept profitieren, indem Sie eine strikte Politik des "absolut Nein null, niemals" einführen. Daher ist OptionalJava beispielsweise nicht so überzeugend, wie es im Idealfall sein sollte.

Ein Optionalbringt stärkere Typisierung in Operationen , die fehlschlagen, da die anderen Antworten werden abgedeckt, aber das ist weit von der interessanteste oder wertvoller Sache Optionalsan den Tisch bringen. Viel nützlicher ist die Möglichkeit, die Überprüfung auf Fehler zu verzögern oder zu vermeiden und viele möglicherweise fehlgeschlagene Vorgänge auf einfache Weise zusammenzustellen.

Überlegen Sie, ob Ihre optionalVariable aus Ihrem Beispielcode stammt, und führen Sie zwei zusätzliche Schritte aus, bei denen jeder möglicherweise fehlschlägt. Wenn ein Schritt auf dem Weg fehlschlägt, möchten Sie stattdessen einen Standardwert zurückgeben. Bei Optionalskorrekter Verwendung erhalten Sie Folgendes:

return optional.flatMap(x -> x.anotherOptionalStep())
               .flatMap(x -> x.yetAnotherOptionalStep())
               .orElse(defaultValue);

Bei nullhätte ich dreimal nullnachsehen müssen, bevor ich fortfahre, was dem Code eine Menge Komplexität und Wartungsprobleme hinzufügt. Optionalshabe diesen check in die flatMapund orElsefunktionen eingebaut .

Hinweis Ich habe nicht isPresenteinmal angerufen , was Sie bei der Verwendung als Code-Geruch betrachten sollten Optionals. Das bedeutet nicht unbedingt, dass Sie niemals verwenden sollten, sondernisPresent nur, dass Sie jeden Code, der dies tut, einer eingehenden Prüfung unterziehen sollten, um festzustellen, ob es einen besseren Weg gibt. Ansonsten haben Sie recht, Sie erhalten nur einen geringfügigen Sicherheitsvorteil gegenüber der Verwendung null.

Beachten Sie auch, dass ich nicht so besorgt bin, dies alles in eine Funktion zu kapseln, um andere Teile meines Codes vor Nullzeigern vor Zwischenergebnissen zu schützen. Wenn es .orElse(defaultValue)zum Beispiel sinnvoller ist, meine in einer anderen Funktion zu haben, habe ich viel weniger Bedenken, sie dort abzulegen, und es ist viel einfacher, die Operationen nach Bedarf zwischen verschiedenen Funktionen zusammenzustellen.

Es wird die Möglichkeit von Null als gültige Antwort hervorgehoben, von der häufig (zu Recht oder zu Unrecht) angenommen wird, dass sie nicht zurückgegeben wird. Durch das Hervorheben der wenigen Male, wenn Null gültig ist, wird vermieden, dass Ihr Code mit einer großen Anzahl sinnloser Nullprüfungen verunreinigt wird.

Idealerweise würde das Setzen einer Variablen auf Null irgendwo anders als optional zu einem Fehler bei der Kompilierung führen. Beseitigen von Laufzeit-Nullzeiger-Ausnahmen. Offensichtlich schließt die Abwärtskompatibilität dies leider aus

Lassen Sie mich Ihnen ein Beispiel geben:

class UserRepository {
     User findById(long id);
}

Es ist ziemlich klar, wofür diese Methode gedacht ist. Aber was passiert, wenn das Repository keinen Benutzer mit der angegebenen ID enthält? Es könnte eine Ausnahme auslösen oder es gibt möglicherweise null zurück?

Zweites Beispiel:

class UserRepository {
     Optional<User> findById(long id);
}

Was passiert hier, wenn kein Benutzer mit der angegebenen ID vorhanden ist? Richtig, Sie erhalten die Instanz Optional.absent () und können sie mit Optional.isPresent () überprüfen. Die Methodensignatur mit Optional bezieht sich expliziter auf den Vertrag. Es ist sofort klar, wie sich die Methode verhalten soll.

Es hat auch einen Vorteil beim Lesen des Client-Codes:

User user = userRepository.findById(userId).get();

Ich habe mein Auge darauf trainiert, .get () als sofortigen Codegeruch zu sehen. Dies bedeutet, dass der Client den Vertrag der aufgerufenen Methode absichtlich ignoriert. Dies ist viel einfacher zu sehen als ohne Optional, da Sie in diesem Fall nicht sofort wissen, welchen Vertrag die aufgerufene Methode hat (ob sie in ihrer Rückgabe null zulässt oder nicht), sodass Sie diese zuerst überprüfen müssen.

Optional wird mit der Konvention verwendet, dass Methoden mit dem Rückgabetyp Optional niemals null zurückgeben, und normalerweise auch mit der (weniger starken) Konvention, dass Methoden ohne den optionalen Rückgabetyp niemals null zurückgeben (es ist jedoch besser, sie mit @Nonnull, @NotNull oder ähnlich zu kommentieren). .

Ein Optional<T>erlaubt Ihnen, "Fehler" oder "kein Ergebnis" als gültigen Antwort- / Rückgabewert für Ihre Methoden zu haben (denken Sie zB an eine Datenbanksuche). Die Verwendung von an Optionalanstelle von, nullum einen Fehler anzuzeigen / kein Ergebnis hat einige Vorteile:

• Er kommuniziert deutlich , dass „Fehler“ ist eine Option. Der Benutzer Ihrer Methode muss nicht raten, ob nulleine Rückgabe möglich ist.
• Der Wert nullsollte, zumindest meiner Meinung nach, nicht dazu verwendet werden, etwas anzuzeigen, da die Semantik möglicherweise nicht vollständig klar ist. Es sollte verwendet werden, um dem Garbage Collector mitzuteilen, dass das zuvor referenzierte Objekt gesammelt werden kann.
• Die OptionalKlasse bietet viele nützliche Methoden, um mit den Werten bedingt zu arbeiten (z. B. ifPresent()) oder Standardwerte auf transparente Weise zu definieren ( orElse()).

Leider muss nullder Code nicht vollständig überprüft werden, da das OptionalObjekt selbst möglicherweise noch vorhanden ist null.

Zusätzlich zu den anderen Antworten besteht der andere Hauptvorteil von Optionals beim Schreiben von sauberem Code darin, dass Sie einen Lambda-Ausdruck verwenden können, falls der Wert vorhanden ist, wie unten gezeigt:

opTr.ifPresent(tr -> transactions.put(tr.getTxid(), tr));

Betrachten Sie die folgende Methode:

void dance(Person partner)

Schauen wir uns nun einen Aufrufcode an:

dance(null);

Dies führt zu einem möglicherweise schwer zu verfolgenden Absturz, da dancekeine Null erwartet wurde.

dance(optionalPerson)

Dies führt zu einem Kompilierungsfehler, da dance ein Personnicht erwartet hatOptional<Person>

dance(optionalPerson.get())

Wenn ich keine Person hatte, führt dies zu einer Ausnahme in dieser Zeile, an dem Punkt, an dem ich unrechtmäßig versucht habe, die Optional<Person>in eine Person umzuwandeln . Der Schlüssel ist, dass anders als bei der Übergabe einer Null die Spuren außer hier nicht an irgendeiner anderen Stelle im Programm sind.

Zusammenfassend lässt sich sagen, dass die missbräuchliche Verwendung von optionalen Elementen das Auffinden von Problemen erleichtert.

In Objective-C sind alle Objektreferenzen optional. Aus diesem Grund ist Code wie Sie dumm.

if (variable != nil) {
    [variable doThing];
}

Code wie der obige ist in Objective-C unbekannt. Stattdessen würde der Programmierer einfach:

[variable doThing];

Wenn variableein Wert enthalten ist, doThingwird er aufgerufen. Wenn nicht, kein Schaden. Das Programm behandelt es als No-Op und läuft weiter.

Dies ist der eigentliche Vorteil von Optionals. Sie müssen Ihren Code nicht mit verunreinigen if (obj != nil).

if (optional.isPresent ()) {

Das offensichtliche Problem hier ist , dass , wenn „optional“ wirklich ist , fehlt (dh null ist) , dann Ihr Code mit einer Nullreferenceexception sprengen wird (oder ähnlich) versucht , auf einer Null - Objekt Referenz jede Methode zu nennen!

Möglicherweise möchten Sie eine statische Helper-Klassenmethode schreiben, mit der die Nullheit eines bestimmten Objekttyps wie folgt bestimmt wird:

function isNull( object o ) 
{
   return ( null == o ); 
}

if ( isNull( optional ) ) ... 

oder vielleicht sinnvoller:

function isNotNull( object o ) 
{
   return ( null != o ); 
}

if ( isNotNull( optional ) ) ... 

Aber sind beide wirklich lesbarer / verständlicher / wartbarer als das Original?

if ( null == optional ) ... 
if ( null != optional ) ...