Arbeitet als ein Team! Stellen Sie sich in Java frontal Null

Ich entschuldige mich für die Erfindung der Null-Referenz auf der Konferenz 2009.

Das ist mein Fehler im Wert von einer Milliarde Dollar.

Null Dies ist ein hasserfülltes Problem, das Entwickler, die unsichere Sprachen verwenden, immer plagt. Informatiker [Antony Hoa | wikipedia](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%88%E3%83%8B% Wie E3% 83% BC% E3% 83% BB% E3% 83% 9B% E3% 83% BC% E3% 82% A2) oben sagte, handelt es sich um eine in die Sprache verwobene technische Verschuldung. Es ist keine Übertreibung zu sagen.

In der modernen Neuentwicklung sind null unsichere Sprachen keine Legacy-Sprachen mehr | Qiita Die Idee, null unsichere Sprachen selbst wie im Artikel zu vermeiden Es wird____geben. Es gibt jedoch immer noch Situationen, in denen Sie eine Sprache auswählen müssen, die aus verschiedenen Gründen nicht null-sicher ist.

Dieses Mal werde ich über die Methode nachdenken, Null in Java zu begegnen.

Vorsichtsmaßnahmen zum Lesen

――Der Gegenmaßnahmenplan hat eine "Empfehlungsstufe", ist jedoch ein persönlicher Eindruck, der auf Erfahrung beruht. ――Die Empfehlungsstufe bei der Aufnahme in ein Team wird in 3 Stufen angezeigt (: star: ~: star :: star :: star :)

Messen

JSR-305 Eine Gruppe von Anmerkungen, die für Software Defect Detection als Java-Spezifikation definiert sind.

Daher wird nicht erwartet, dass eine Annotation in Runtime funktioniert, sondern eine Spezifikation, die zum Zeitpunkt der Entwicklung als ** Hilfsfunktion ** definiert wurde (z. B. Unterstützung in IDEs wie Find Bugs und IntelliJ).

Deklarieren Sie, ob der Rückgabetyp "null" ist

Empfehlungsstufe :: star :: star :: star:

import javax.annotation.Nullable;

@Nullable
public String createText() {
    // ...

import javax.annotation.Nonnull;

@Nonnull
public String createText() {
    // ...

Es ist sehr wichtig, die Check-Support-Funktion nutzen zu können, aber ich hatte das Gefühl, dass die Effektivität in den folgenden Punkten bei der Arbeit im Team maximiert wird.

Die Absicht jeder Methode des Designers / Implementierers kann klar verlassen werden.
Als Nebeneffekt verbessert sich die Qualität zum Zeitpunkt der Überprüfung
Reduziert den Aufwand von Implementierern, die Methoden verwenden, um Null zu berücksichtigen
Reduzierte unnötige Nullprüfungen

Deklarieren Sie, ob im Argument "null" zulässig ist

Empfehlungsstufe :: Stern:

import javax.annotation.Nullable;
import javax.annotation.Nonnull;

public String createText(@Nonnull String id,
                         @Nullable String option) {
    // ...

Während die gleichen Vorteile wie "Angeben, ob der Rückgabetyp" Null "ist" erzielt werden können, fallen die folgenden Nachteile für das Team auf.

Es ist mühsam, für alle Argumente hinzuzufügen ――Weil es lästig ist, ist es leicht, eine bloße Leiche zu werden
Das Argument geht in den Zustand des Anmerkungsfestivals über, und die Sichtbarkeit sinkt.

Java 8+ Standard `Optional`

`Optional` schlägt `null` als Rückgabetyp vor

Empfehlungsstufe :: Stern:

import java.util.Optional;

public Optional<String> getText() {
   // ...

Java 8 Optional wird in vielen Artikeln erwähnt, daher werde ich nicht auf Details eingehen. Die Gründe, warum wir es hier nicht empfehlen, sind folgende.

Der Typ "Optional" ist keine serialisierbare Klasse, daher ist seine Verwendung begrenzt.
Regeln brechen wahrscheinlich in Fällen, in denen Bibliotheken (insbesondere O / R Mapper) nicht unterstützt werden

■ Referenz

Anweisungsprogrammierung

"Ausdrucksprogrammierung", die die in Master Programmer eingeführten Voraussetzungen überprüft. Es ist sehr wertvoll, weil Sie damit das "übergeordnete Konzept" des Designers / Implementierers als Code belassen können.

Testen Sie die Programmannahmen mit "assert"

Empfehlungsstufe :: star :: star:

private String createText(String id) {
    assert (id != null) : "id must not be null.";
    // ...

Ein typisches Beispiel für Express-Programmierung in Java ist "assert". Beachten Sie jedoch die folgenden Punkte im Code (Programmieren mit Zusicherungen | oracle.com). Auszug aus assert.html)

■ Aktivieren und Deaktivieren von Zusicherungen ** Standardmäßig sind Zusicherungen zur Laufzeit deaktiviert **. Sie können zwei Befehlszeilenoptionen verwenden, um Zusicherungen zu aktivieren / deaktivieren. Verwenden Sie die Schalter -enable Assertions oder -ea, um Assertions auf verschiedenen Detailebenen zu aktivieren.

Es kann gelesen werden, dass "assert" nur ein Hilfsmittel ist, um die Absicht des Implementierers auszudrücken, und nicht, um eine Ausnahme in der Laufzeit des Produktcodes auszulösen. Wenn Sie das offizielle Dokument sorgfältig lesen, werden wichtige Informationen wie die Verarbeitung mit Nebenwirkungen beschrieben. Daher muss überlegt werden, welche Art von Punkt bei der Annahme zu verwenden ist.

Nutzen Sie die Behauptungen der Bibliothek

Empfehlungsstufe :: star :: star :: star:

import org.springframework.util.Assert;

public String createText(String id) {
    Assert.notNull(id, "ID must not be null.");
    // ...

Für das Spring Framework org.springframework.util.Assert Verwendung ist das.

Im Gegensatz zu Java Assertion wird auch zur Laufzeit eine Ausnahme ausgelöst. Es ist eine Vereinfachung der Nullprüfung, funktioniert aber auch mit Runtime, sodass Sie dem Implementierer eine sehr starke Absichtserklärung in Ihrem Code hinterlassen können.

Indirekte Nullverteidigung

Deklarieren Sie die Variable "final", um sie unveränderlich zu machen

Empfehlungsstufe :: star :: star:

public String createText(final String id) {
    // ...

public String createText(String id) {
    final String prefix = something(id);
    // ...

Die Verwendung von "final" scheint nicht in direktem Zusammenhang mit "null" zu stehen. In Kombination mit der Nicht-Null-Garantie in Assertion können Sie jedoch in Ihrer Methode fast vollständig Nicht-Null-Garantie garantieren. Infolgedessen können Sie unnötige Verarbeitungen wie "Ich weiß nicht, was kommen wird, also prüfen Sie vorerst" null "in der Zwischenverarbeitung sicher löschen.

Sammlung unveränderlich machen

Empfehlungsstufe :: star :: star:

Java-Standard

import java.util.Collections;

public String createText() {
    List immutables = Collections.singletonList("value1", "value2");
    // ...

import java.util.Collections;

public String createText() {
    Map<String, String> immutables = Collections.singletonMap("key1", "value1");
    // ...

import java.util.Collections;

public List<Store> fetchStores() {
   List<Store> stores  = findAll();
   
   return Collections.unmodifiableCollection(stores);

Guava

import com.google.common.collect.ImmutableMap;

public String createText() {
    Map<String, String> immutables = ImmutableMap.of("key1", "value1", "key2", "value2");
    // ...

import com.google.common.collect.ImmutableList;

public String createText() {
    List<String> immutables = ImmutableList.of("value1", "value2");
    // ...

Es ist eine ziemlich lokale Verteidigung, wenn es um unveränderliche Sammlungen geht.

Es verringert das Risiko, "Null" -Elemente in eine einmal erstellte Sammlung zu mischen, mit dem Ziel, "Null" -Ausnahmen bei der nachfolgenden Zwischenverarbeitung zu berücksichtigen. Es ist nüchtern, aber es sollte so viel wie möglich aufgenommen werden.

Beispiel

Mal sehen, wie sehr sich die Informationsmenge vor / nach der Anwendung tatsächlich unterscheidet.

before

public class StoreService {
    
    public Store fetchStore(String storeId){
        // ...
    }

    public List<Store> fetchSisterStores(String storeId){
        // ...
    }

    public List<Coupon> fetchCoupons(String storeId,
                                         List<Category> categories){
        // ...
    }
}

after

public class StoreService {

    @Nonnull
    public Store fetchStore(final String storeId) {
        Assert.notNull(storeId, "store-id must not be null.");
        // ...

    }

    @Nullable
    public List<Store> fetchSisterStores(final String storeId) {
        Assert.notNull(storeId, "store-id must not be null.");

        // ...
    }

    @Nonnull
    public List<Coupon> fetchCoupons(final String storeId,
                                     final List<Category> categories) {
        Assert.notNull(storeId,    "store-id must not be null.");
        Assert.notNull(categories, "categories must not be null.");

        // ...
    }
}

Ist es nicht ein ausdrucksstärkerer Code? Wenn Sie nur ein paar Zeilen vor und nach der Signatur lesen, können Sie die meisten Beispiele sofort abrufen, und der Code ist benutzerfreundlich.

Aus Sicht des Überprüfers ist der Unterschied in den Spezifikationen des von "fetchSisterStores (...)" und "fetchCoupons (...)" zurückgegebenen "List" -Typs offensichtlicher, und die Qualität der Überprüfung wird sich wahrscheinlich verbessern.

Zusammenfassung

Wählen Sie als Team die Gegenmaßnahmen "Null" und reduzieren Sie die durch "Null" verursachten technischen Schulden bis zum Äußersten! Und lassen Sie uns die folgenden Vorteile mit dem gesamten Team realisieren!

Verbesserte Lesbarkeit des Codes
Verbesserte Überprüfungsqualität
Reduzierung der Nächte, in denen das Kissen mit Nurpo nass wird

Lass uns ein gutes Nullleben haben!

Arbeitet als ein Team! Stellen Sie sich in Java frontal Null

Vorsichtsmaßnahmen zum Lesen

Messen

Deklarieren Sie, ob der Rückgabetyp "null" ist

Deklarieren Sie, ob im Argument "null" zulässig ist

Java 8+ Standard Optional

Optional schlägt null als Rückgabetyp vor

Anweisungsprogrammierung

Testen Sie die Programmannahmen mit "assert"

Nutzen Sie die Behauptungen der Bibliothek

Indirekte Nullverteidigung

Deklarieren Sie die Variable "final", um sie unveränderlich zu machen

Sammlung unveränderlich machen

Java-Standard

Beispiel

Zusammenfassung

Java 8+ Standard `Optional`

`Optional` schlägt `null` als Rückgabetyp vor