Java Optional: Nutzung als Getter? Angenommen?

[iTobi97]

Hallo liebe Community,

ich bin vor ein paar Tagen auf Java Optional gestoßen, und stelle mir bis heute die Frage nach den Anwendungsfällen dieses Konstrukts. Ich würde Optional sehr hilfreich bei Gettern finden, die auf ein Referenztyp verweisen und somit auch null zurückliefern könnten. Allerdings bin ich mir nicht sicher, ob Optionals für diese Fälle gedacht sind und in welchen Bereichen sie sonst noch bzw. nicht Anwendung finden sollten. Ich bin kein großer Fan von NullPointerExceptions und ich finde es auch häufig immer sehr unschön, diese null Überprüfungen bei allen Übergabeparametern durchzuführen.

Ich freue mich auf eure Meinung dazu!

 

[Flown]

Naja Optional ist eher gedacht als eine Represäntation für "nicht vorhanden". Wenn aber dein member null sein darf, dann ist Optional keine Option xD.

 

[iTobi97]

@Flown Naja, es kann halt sein, dass ein Wert z.B. noch nicht gesettet wurde (und der nicht explizit im Konstruktor stehen muss) und durch die Rückgabe eines Optionals könnte der Methoden-Aufrufer direkt seine Funktionalität mit den Methoden der Optional-Klasse implementieren und muss somit nicht explizit eine Nullüberprüfung durchführen? Oder habe ich da was falsch verstanden?

 

[Flown]

Naja, es kann halt sein, dass ein Wert z.B. noch nicht gesettet wurde (und der nicht explizit im Konstruktor stehen muss)

Dann ist dieser Wert nicht mandatory und kann somit null sein IMHO.

und durch die Rückgabe eines Optionals könnte der Methoden-Aufrufer direkt seine Funktionalität mit den Methoden der Optional-Klasse implementieren und muss somit nicht explizit eine Nullüberprüfung durchführen?

Klar, hab auch nichts anderes behauptet. Die Sache ist nur ob man xxx != null oder opt.isPresent schreiben will. Ist für mich Jacke wie Hose.

 

[mrBrown]

Für mich wäre das durchaus der Fall für Optional als Rückgabetyp des Getter, wenn der Wert optional ist

Im Gegensatz zu einfachem null drückt man da ja zusätzlich auch noch ganz bewusst aus, dass der Wert null werden kann und kann zusätzlich recht angenehm mit dem Wert weiter arbeiten, oftmals ohne explizite Überprüfung.

 

[iTobi97]

@mrBrown Also würdest du unterstützen, dass bei Werte die nicht über den Konstruktor initialisiert werden, ein Optional als Rückgabetyp durchaus Sinn machen kann? Fallen dir noch andere Anwendungsgebiete dafür ein?

@Flown Ja, einerseits ist es nur eine andere Schreibweise, aber wenn nicht ich selbst den Getter aufrufe, und ein anderer Programmierer mit meinen Methoden arbeitet, und nicht achtsam auf mögliche Null-Werte überprüft, wird er bei der Verwendung von Optionals implizit dazu gezwungen bzw. explizit darauf hingewiesen, da das Rückgabeobjekt vom Typ Optional ist. Daher wäre er eigentlich dazu genötigt, eine Null-Überprüfung durchzuführen.

 

[mrBrown]

@mrBrown Also würdest du unterstützen, dass bei Werte die nicht über den Konstruktor initialisiert werden, ein Optional als Rückgabetyp durchaus Sinn machen kann? Fallen dir noch andere Anwendungsgebiete dafür ein?

Ob der Konstruktor das Feld initialisiert oder nicht ist mMn unerheblich - relevant ist, ob Optional sinnvolle die Intention ausdrückt. An manchen Stellen ist das gut mit Optional umzusetzen, an anderen nicht.

 

[iTobi97]

@mrBrown Also z.B. wenn es für den Nutzer wichtig ist, ob das Rückgabe-Argument des Getters null ist?

 

[mrBrown]

"Wichtig" ist relativ, es sollte halt das Verständnis der Schnittstelle fördern.

 

[Flown]

@Flown Ja, einerseits ist es nur eine andere Schreibweise, aber wenn nicht ich selbst den Getter aufrufe, und ein anderer Programmierer mit meinen Methoden arbeitet, und nicht achtsam auf mögliche Null-Werte überprüft, wird er bei der Verwendung von Optionals implizit dazu gezwungen bzw. explizit darauf hingewiesen, da das Rückgabeobjekt vom Typ Optional ist. Daher wäre er eigentlich dazu genötigt, eine Null-Überprüfung durchzuführen.

Grundsätzlich: Es kommt immer auf den Use-Case an.
Optional ist kein built-in type und somit müsstest du - wie es aussieht, paranoider Programmierer - auch die Optional überprüfen, ob diese null sind .

In meine Augen liefert Optional nicht wirklich einen Mehrwert. Entwickler können einfach, ohne isPresent Abfrage, get() aufrufen und dann wäre es das Gleiche, als ob man eine NullPointerException bekommt. Nochmal: Es kommt stark auf den Use-case an und ob man möchte, dass null ein Sonderfall ist.

 

[AndyJ]

Wenn du eine Methode schreibst, die nicht immer einen Wert zurueckliefern kann und wenn du denkst, dass dies fuer den Nutzer deiner Methode wichtig ist, dann kann man Optional verwenden. Eine Methode, die null zurueckliefern kann benoetigt korrekte Javadocs um diese Information zu transportieren (e.g. @Return ein Wert oder null). Das zwingt den Nutzer aber leider nicht sich auch darum zu kuemmern, waehrend bei einem Optional klar ist, dass dieser leer sein kann.
Wenn du deine Methode im Zusammenhang mit Streams verwenden willst, ist Optional auch eine gute Wahl.

Auf der anderen Seite bedeutet die Verwendung von Optional auch Performanceeinbussen; ein Optional muss wie jedes andere Object ja auch erst einmal erzeugt werden und braucht Speicherplatz. Daher wuerde ich Optional nicht fuer performancekritische Anwendungen verwenden.
Ein Optional ist ein Containertyp, daher sollte man fuer andere Containertypen Optional nicht verwenden (z.B. Arrays, Collections, etc.). In solchen Faellen gibt man lieber einen leeren Container oder ein Array mit 0 Elementen zurueck.
Eine weitere Option ist es einen Default-Wert zurueckzugeben anstatt null oder Optional. Das funktioniert aber nicht immer, es haengt von der Semantik deiner Methode ab.

Cheers,
Andy

 

[mrBrown]

Auf der anderen Seite bedeutet die Verwendung von Optional auch Performanceeinbussen; ein Optional muss wie jedes andere Object ja auch erst einmal erzeugt werden und braucht Speicherplatz. Daher wuerde ich Optional nicht fuer performancekritische Anwendungen verwenden.

Wobei das nahezu immer "inlined" werden sollte und damit sowohl der Overhead durch das Objekt als auch die Methodenaufrufe wegfallen und es nicht langsamer ist, als ein "normaler" Rückgabetyp und normaler null-check