Sollten Java 8-Getter den optionalen Typ zurückgeben?

Optional Typ eingeführt in Java 8 ist eine neue Sache für viele Entwickler.

Ist eine getter Methode zurückgeben Optional<Foo> Art an die Stelle der klassischen Foo eine gute Praxis? Davon ausgehen dass der Wert kann null.

Kommentar zu dem Problem
Obwohl dies wahrscheinlich zu gewinnen rechthaberisch Antworten, es ist eine gute Frage. Ich freue mich auf eine Antwort mit realen Fakten zu dem Thema. Kommentarautor: Justin
Die Frage ist, ob die nullablitity unvermeidbar ist. Eine Komponente, eine Eigenschaft, die erlaubt ist, null sein, aber trotzdem ist der Programmierer mit dieser Komponente können entscheiden, halten fest, dass die Eigenschaft nicht-null. Also die Programmierer sollten nicht zu tun haben mit Optional dann. Oder, in anderen Worten, null wirklich repräsentieren die Abwesenheit eines Wertes, wie mit dem Ergebnis der Suche (wobei Optional geeignet ist) oder null nur ein Element der Menge der möglichen Werte. Kommentarautor: Holger
Siehe auch die Diskussion auf @NotNull Anmerkungen: stackoverflow.com/q/4963300/873282 Kommentarautor: koppor

InformationsquelleAutor der Frage leonprou | 2014-10-12

  1. 320

    Natürlich werden die Menschen tun, was Sie wollen. Aber wir haben eine klare Absicht, wenn das hinzufügen dieses feature, und es war nicht einen Allgemeinen Zweck oder Vielleicht Einige geben, wie viel, wie viele Menschen gefallen hätte, uns zu tun. Unsere Absicht war es, eine begrenzte Mechanismus für die Bibliothek-Methode return-Typen, wo es benötigt wird, um eine klare Darstellung von "kein Ergebnis", und mit null für solche überwiegend wahrscheinlich zu Fehlern führen.

    Zum Beispiel, sollten Sie wahrscheinlich verwenden Sie Sie nie für etwas, das gibt ein array der Ergebnisse, oder eine Liste von Ergebnissen; statt return ein leeres array oder eine Liste. Sie sollten fast nie verwenden Sie es als ein Feld von etwas oder einen parameter einer Methode.

    Denke ich routinemäßig mit es als Rückgabewert für Getter würde auf jeden Fall mehr verwenden.

    Gibt es nichts falsch mit Optional, es sollte vermieden werden, es ist einfach nicht das, was viele Menschen wollen es, und entsprechend waren wir ziemlich besorgt über die Gefahr, die von eifrigen über-Einsatz.

    (Public service announcement: NIE nennen Optional.get es sei denn, Sie beweisen können, dass es nie null sein; stattdessen verwenden Sie eine der sicheren Methoden wie orElse oder ifPresent. Im Nachhinein sollten wir genannt haben get etwas wie getOrElseThrowNoSuchElementException oder etwas, das es weit klarer, dass dies war eine höchst gefährliche Methode, die untergraben den gesamten Zweck Optional in den ersten Platz. Lektion gelernt. (UPDATE: Java 10 hat Optional.orElseThrow(), die semantisch äquivalent zu get(), aber deren Namen ist besser geeignet.))

    InformationsquelleAutor der Antwort Brian Goetz

  2. 55

    Nachdem ich ein wenig Forschung meiner eigenen, ich bin gekommen, über eine Reihe von Dingen, die darauf hindeuten könnten, wenn dies zweckmäßig ist. Der angesehensten wird das folgende Zitat aus einer Oracle-Artikel:

    "Es ist wichtig zu beachten, dass die Absicht, die Optionale Klasse ist nicht zu ersetzen, jedes einzelne null-Verweis. Stattdessen ist Ihre Aufgabe zu helfen, design mehr-verständlich-APIs, so dass nur durch das Lesen der Signatur einer Methode, können Sie sagen, ob Sie erwarten können, ist ein optionaler Wert. Dies zwingt Sie dazu, aktiv freilegen eines Optional Umgang mit der Abwesenheit eines Werts." - Müde von Null-Pointer-Ausnahmen? Erwägen Sie die Verwendung von Java SE 8 ist Optional!

    Fand ich auch diesen Auszug aus Java 8 Optional: Wie es zu benutzen

    "Optional ist, soll nicht verwendet werden, die in diesen zusammenhängen, als es nicht kaufen uns etwas:

    • in das domain-Modell-Ebene (nicht serialisierbar)
    • in DTOs (aus demselben Grund)
    • in Eingabeparameter von Methoden
    • in Konstruktor-Parameter"

    Denen scheint auch zu erhöhen, einige gültige Punkte.

    War ich nicht in der Lage zu finden, keine negativen Konnotationen oder rote Fahnen zu vermuten, dass Optional sollte vermieden werden. Ich denke, die Allgemeine Idee ist, wenn es hilfreich oder verbessert die usability Ihrer API, verwenden Sie es.

    InformationsquelleAutor der Antwort Justin

  3. 11

    Ich würde sagen, im Allgemeinen ist es eine gute Idee, verwenden Sie die optionale type-für return-Werte, null-Werte zulassen. Jedoch, w.r.t. der Rahmen ich nehme an, dass die Ersetzung klassischer Getter mit optionalen Typen verursachen eine Menge Probleme bei der Arbeit mit frameworks (z.B. Hibernate), die sich auf kodierungskonventionen für Getter und setter.

    InformationsquelleAutor der Antwort Claas Wilke

  4. 2

    Wenn Sie sind mit modernen serialisierungsprogramme und anderen frameworks, die verstehen Optional ich dann diese gefunden haben Richtlinien gut funktionieren, wenn das schreiben Entity Bohnen und domain Ebenen:

    1. Wenn die Serialisierung Schicht (in der Regel DB) ermöglicht eine null Wert für eine Zelle in Spalte BAR in Tabelle FOO, dann die getter Foo.getBar() zurückkehren können Optional Angabe der Entwickler, dass dieser Wert kann vernünftigerweise erwartet werden, zu null und Sie sollten damit umgehen. Wenn die DB garantiert der Wert nicht null, dann die getter sollten nicht wickeln Sie diese in ein Optional.
    2. Foo.bar sollte private und nicht werden Optional. Es gibt wirklich keinen Grund für es zu sein Optional wenn es private.
    3. Setter Foo.setBar(String bar) sollte die Art der bar und nicht Optional. Wenn es OK ist, zu verwenden null argument, dann Stand dies in der JavaDoc-Kommentar. Wenn es nicht OK ist null eine IllegalArgumentException oder einige entsprechende business-Logik ist, IMHO, besser geeignet.
    4. Konstruktoren müssen nicht Optional Argumente (aus ähnlichen Gründen, Punkt 3). Generell kann ich mir nur Argumente im Konstruktor, dass muss werden, die nicht null in der Serialisierung Datenbank.

    Machen die oben genannten effizienter, möchten Sie vielleicht zu Bearbeiten Sie Ihre IDE-Vorlagen für die Generierung von get-und entsprechende Vorlagen für toString(), equals(Obj o) etc. oder verwenden Sie Felder direkt für diejenigen (die meisten IDE-Generatoren befassen sich ohnehin mit null).

    InformationsquelleAutor der Antwort Mark

Schreibe einen Kommentar