[JAVA] null und optionale Typen und Ideale und Realität

Vor kurzem habe ich angefangen, mobile Apps zu entwickeln und Swift und Kotlin zu studieren. Unter solchen Umständen habe ich zuerst das Konzept des "optionalen Typs" angesprochen und mich gefragt, ob es eine Sprache gibt, die einen so bequemen Typ hat. Nach sorgfältiger Prüfung stellte ich jedoch fest, dass Java 8 auch den optionalen Typ hat. Ich wusste es jetzt. Das Folgende ist JavaDoc über Optional. https://docs.oracle.com/javase/jp/8/docs/api/java/util/Optional.html

Was ist der optionale Typ?

Ein Variablentyp, der "null" (in einigen Sprachen "nil") speichern kann. In Java können ** primitive Typen ** wie int und boolean nicht null (Kompilierungsfehler) speichern, aber ** Referenztyp ** -Variablen wie Integer und String sind` Da null "gespeichert werden kann, kann eine" NullPointerException "auftreten, wenn Sie" null "nicht im Voraus überprüfen.

Vorteile des optionalen Typs

Die erste Frage fühlte ich mich als Programmanfänger.

Da der Referenztyp auch in "null" enthalten ist, müssen Sie sich nicht die Mühe machen, den "optionalen" Typ zu definieren, oder?

Sicherlich ist im Sinne von "einem Typ, der" null "sein kann" weder der optionale Typ noch der Referenztyp relevant. Das Wichtigste ist, dass im Fall eines Referenztyps "null" überprüft werden muss und es leicht zu vernachlässigen ist. Wenn Sie es versäumen, "null" zu aktivieren, erhalten Sie eine "NullPointerException". Da dies jedoch eine Laufzeitausnahme ist, werden Sie im schlimmsten Fall möglicherweise nicht bemerken, dass es sich nicht um einen Produktionsfehler handelt.

String str = getString();//Wenn dies null zurückgibt
//Wenn Sie die folgende if-Anweisung vergessen, wird sie kompiliert, aber zur Laufzeit erhalten Sie eine NullPointerException.
//if(str == null){
//    str = "";
//}
return str.length();

Wenn andererseits der optionale Typ verwendet wird, kann der Wert nur abgerufen werden, wenn eine dedizierte Methode verwendet wird. Daher muss ** unter Berücksichtigung des Falls "null" codiert werden. ** **. Mit anderen Worten, ich denke, der größte Vorteil ist, dass Sie nicht verpassen werden, was zu tun ist, wenn "null" unbeabsichtigt eingegeben wird.

Optional<String> opt = Optional.ofNullable(getString());
String str = opt.orElse(""); //So rufen Sie einen Wert von Optional ab, einer Methode, die null berücksichtigt`orElse`Es kann nicht ohne Verwendung herausgenommen werden.
return str.length();

Aber ursprünglich sollten wir unerwartete Nullen beseitigen

Warum. Ich habe es all die Tage vergessen, aber es ist nicht wichtig, im Falle einer unerwarteten Situation sicher zu sein (aktivieren Sie "null"), und es ist nicht wichtig, etwas Unerwartetes zu tun. Es ist wichtiger, es nicht zu machen (beseitigen Sie die Ursache für die Rückgabe von "null").

Wenn Sie es mit dem obigen Code vergleichen,

String str = getString();//Ist es nicht schlecht für getString, überhaupt null zurückzugeben?
//Der folgende Prozess sollte beschrieben worden sein, aber getString()Ist in den Spezifikationen nicht aufgeführt, um null zurückzugeben
//if(str == null){
//    str = "";
//}
return str.length();

Das ist der Fall. Ist es nicht einfach zu glauben, dass es vorerst sicher ist, "null" zu überprüfen, ohne zu wissen, wer (welcher Code) für die Berücksichtigung von "null" verantwortlich ist?

Erfahrungsgemäß ist das Modul, das dem Präzedenzfall "getString" entspricht, ein Voraussetzungmodul, das vor langer Zeit von einem anderen Anbieter hergestellt wurde, oder es wird auch auf andere Systeme umgeleitet, die bereits in Betrieb sind, sodass es mit den Wartungskosten des Vertragsprojekts usw. zusammenhängt. Aus diesem Grund wird es oft als "Modul, das nicht repariert werden kann" behandelt, und es wird überwiegend entsprechend der Situation codiert, dass "es keine andere Wahl gibt, als realistisch zu denken" als der Idee, dass "es als Design sein sollte". Es gibt viele.

Der Grund, warum ich mich entschlossen habe, diesen Artikel zusammenzustellen, ist, dass ich mit der Tatsache zufrieden bin, dass ich keine andere Wahl habe, als in letzter Zeit realistisch zu denken, und ich werde ihn implementieren, indem ich einfach denke, dass es sicher ist, vorerst "null" zu überprüfen. Weil ich das Gefühl hatte, es sei geworden.

Es ist bekannt, dass das Modul ursprünglich nicht "null" gemacht wurde, sondern als Implementierung belassen wurde, in der "null" vom Programmierer versehentlich eingegeben wurde, und dass es absichtlich "null" gemacht wurde. Die Beurteilung, dass "es in diesem Fall unmöglich ist," null "zu werden", ist schlecht, da die Vererbung des Inhalts "absichtlich" null "gemacht wird, ohne oder im Laufe der Zeit unterbrochen zu werden.

Zusammenfassung

Der optionale Typ kann den Programmierer zwingen, den Fall von "null" zu betrachten, aber die Idee, zu entwerfen, wie mit "null" umgegangen werden soll, sollte nicht vergessen werden. (← Gebote an dich selbst)

Wenn beispielsweise "getString ()" ein Modul ist, das "null" zurückgeben kann, sollte der Rückgabewert von "getString ()" ebenfalls optional sein.

Optional<String> opt = getString();//Sollte ausdrücklich angegeben werden, um einen optionalen Typ zurückzugeben
String str = opt.orElse("");
return str.length();

Wenn alternativ garantiert werden soll, dass "getString ()" nicht "null" zurückgibt, kann die interne Verarbeitung von "getString ()" geändert werden, sodass der Aufrufer den optionalen Typ nicht verwendet.

String str = getString();//Wenn garantiert, dass es absolut nicht null ist
//Die folgende if-Anweisung ist toter Code, daher ist es richtig, sie nicht zu implementieren
//if(str == null){
//    str = "";
//}
return str.length();

Selbst in neuen Sprachen wie Swift und Kotlin, die Optional verwenden können, sollte diese Idee nicht vergessen werden.