it-swarm.com.de

Ist die Verwendung von Optional.ofNullable als Ersatz für den ternären Operator eine bewährte Methode?

Berücksichtigen Sie die Verwendung dieses Ausdrucks:

String hi = Optional.ofNullable(sayHi()).orElse("-");

was effektiv diesem ternären Ausdruck entspricht:

String hi = sayHi() != null ? sayHi() : "-";

Ist diese Verwendung von Optional.ofNullable mit einem Methodenaufruf eine bewährte Methode? Oder nur extra weite Codierung?


Ich erkenne, dass Optional.ofNullable tatsächlich eine Variable erstellt und den zweimaligen Aufruf der sayHi()-Methode vermeidet. Um dieses Problem zu vermeiden, können Sie tatsächlich eine zusätzliche Variable erstellen, dies erhöht jedoch die Ausführlichkeit der ternären Option:

String hi = sayHi();
hi = hi != null ? hi : "-";

Andererseits erstellt Optional.ofNullable, falls hi nicht null ist, ein zusätzliches Optional-Objekt. Es gibt also sicherlich mehr Aufwand.

Es scheint also einige Vor- und Nachteile zu geben, diesen Konstrukt als Ersatz für den ternären Konstruktor zu verwenden.


Übrigens: Dies ist die Java 8-Implementierung von Optional.ofNullable:

public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
}
7
gil.fernandes

Immer wenn ich daran denke, die optionale API für einen bestimmten Zweck zu verwenden, erinnere ich mich immer daran, was beabsichtigt war und warum es in das JDK aufgenommen wurde. 

Optional in soll ein begrenzter Mechanismus für die Bibliotheksmethode zur Verfügung stellen Rückgabetypen, bei denen eindeutig "kein Ergebnis" und .__ dargestellt werden müssen. wo null zu verwenden ist, wird mit großer Wahrscheinlichkeit Fehler verursachen - Stuart Marks 

Optional konzentriert sich in erster Linie auf einen Rückgabetyp, der möglicherweise einen Rückgabewert enthält. 

Wenn Sie dieses Konstrukt wie in diesem speziellen Beispiel verwenden, führt dies zu zusätzlicher Speicherzuordnung und zusätzlichem GC-Aufwand.

Ich halte die Dinge einfach und tue stattdessen:

String hi = sayHi();
if(hi == null) hi = “-“;
...
11
Aomine

Verwenden Sie in JDK 9 oder höher Folgendes:

String hi = Objects.requireNonNullElse(sayHi(), "-");

Dadurch wird vermieden, dass sayHi() wiederholt werden muss, wenn ein ternärer Operator verwendet wird, oder der Wert einer lokalen Variablen zugewiesen wird, die innerhalb des ternären Objekts wiederverwendet wird. Es könnte eine kleine Verbesserung sein. Es übergeht auch die Frage, ob Optional verwendet werden soll. :-)

9
Stuart Marks

Ist diese Verwendung von Optional.ofNullable mit einem Methodenaufruf eine bewährte Methode?

Konzeptionell , es ist eine schlechte Praxis. Die Grundidee besteht darin, das Fehlen eines Rückgabewerts darzustellen, und nicht alles umzugehen, was null sein könnte. Ich bin stark gegen diese Verwendung.

Oder nur extra weite Codierung?

Es sieht für mich wie ein fehlgeschlagener Versuch aus, Ihren Code modischer zu gestalten. ("Schauen Sie, wir verwenden brandneue Optional von Java 8!") 

Ich bevorzuge Lesbarkeit und Klarheit der Prägnanz.

Diese Optinal-Verwendung bietet keine Klarheit, wirft jedoch Fragen auf:

Warum wickeln Sie die Variable ein?
Was machen Sie mit dieser Optional?
Wird es unten verwendet/zurückgegeben?
 

Es gibt auch keine Kürze: Ihre zweite Zeile ist noch kürzer.

Um dieses Problem zu vermeiden, können Sie tatsächlich eine zusätzliche Variable erstellen, dies erhöht jedoch die Ausführlichkeit der ternären Option.

Sie erstellen keine zusätzliche Variable. Die einzeilige Version könnte sein:

String hi = (hi = sayHi()) != null ? hi : "-";

Ihr zweizeiliger Vorschlag ist jedoch absolut in Ordnung:

String messageContent = sayHi();
String hi = messageContent != null ? messageContent : "-";
6
Andrew Tobilko

Wenn Sie Optional in Ihren Workflow zulassen möchten, sollten Sie die sayHi()-Methode so ändern, dass Optional<String> zurückgegeben wird, wodurch das Ergebnis eleganter wird:

hi = sayHi().orElse("-");

Wenn Sie Optional nicht in Ihren Arbeitsablauf einführen möchten (da dadurch ein zusätzliches Objekt erstellt wird, das den optionalen Wert enthält), sollten Sie sich an einfache Nullprüfungen und den ternären Operator halten.

In Bezug auf die Leistungskosten von Optional (z. B. mehr Speicherbereinigung) müssen Sie Ihre Anwendung profilieren und entscheiden, ob dies ein echtes Problem darstellt.

Wenn Sie vor allem an String interessiert sind, beachten Sie die Objects.toString(Object, String)-Methode, die einen Standardwert zurückgibt, wenn das Objekt den Wert null hat:

hi = Objects.toString(hi, "-");

Dies ist aufgeräumter und eleganter, als den Code manuell herauszuschreiben.

5
Bobulous

Kurz gesagt: Vermeiden Sie den Optional-Typ . Das Hauptargument für Optional für Rückgabetypen lautet: "Es ist für Clients zu einfach, die Möglichkeit eines Rückgabewerts mit Null zu vergessen. Optional ist hässlich und in Ihrem Gesicht, daher ist es weniger wahrscheinlich, dass ein Client die Möglichkeit eines leeren Rückgabewerts vergisst. Überall sonst sollten Programmierer weiterhin normale Referenzen verwenden, die null sein könnten. " 

Ich schrieb eine Diskussion über die Vor- und Nachteile der Verwendung von Javas Optional-Typ: Nichts ist besser als der optionale Typ .

0
mernst

Ich denke, es ist hauptsächlich eine Frage des persönlichen Geschmacks.

Aus meiner Sicht wäre es sinnvoller, einfach einen Optional<String> zurückzugeben und den Anrufer mit einem fehlenden Wert umgehen zu lassen.

Optional, da es sich um einen monadischen Typ handelt, kann mehr genutzt werden als nur einen Alt-Wert zu erhalten.

Auf der anderen Seite scheint Ihr Operator knapp genug zu sein, wenn er konsequent verwendet wird, kann dies praktisch sein.

Ich denke nicht, dass Leistung hier ein großes Problem darstellt.

0
minus