Ich habe versucht, Effective Java 3rd Edition "fast alle Kapitel" in "leicht lesbarem Japanisch" zu erklären.

Ich denke, Effective Java ist ein unvermeidliches Buch, um ein "vollwertiger" Java-Ingenieur zu werden. Insbesondere Ingenieure, die in der Lage sind, öffentliche APIs zu erstellen, können nur dann anständige APIs erstellen, wenn sie verstehen, was in diesem Buch geschrieben steht.

Es versteht sich von selbst, dass es ein wunderbares Buch ist, aber andererseits denke ich auch, dass es ein Buch ist, das schwer zu verstehen ist: "Kurz gesagt, das ist es."

Die Ursache ist wahrscheinlich wie folgt.

• Der Ausdruck ist Kreisverkehr.
• Insgesamt gibt es 90 Elemente, aber die Struktur innerhalb der Elemente ist schwer zu verstehen.
• Codebeispiele können komplexer als nötig sein.

Das Wesentliche des Inhalts selbst ist nicht sehr schwierig, aber ich finde es schade, dass die Schwelle dieses Buches aus diesem Grund angehoben wird.

Daher möchte ich in diesem Artikel (fast) alle Artikel in "leicht lesbarem Japanisch" so weit wie möglich erklären.

Ich habe jedoch Erklärungen für Elemente weggelassen, die zu offensichtlich oder leicht zu lesen sind. Auch meine persönliche Meinung ist gemischt. Ich hoffe, Sie können es unter dieser Voraussetzung sehen.

Effektive Java 3rd Edition wurde für Java 9 geschrieben. Daher werde ich die offizielle Java 9-Dokumentation für alle Fälle veröffentlichen (da sie unerwartet schwer zu erreichen ist).

[Java 9] Offizielles Dokument oben https://docs.oracle.com/javase/jp/9/

[Java 9] JDK Javadoc (gefolgt vom oberen Bildschirm) https://docs.oracle.com/javase/jp/9/docs/toc.htm

[Java 9] Java-Sprachspezifikationen (gefolgt vom oberen Bildschirm) https://docs.oracle.com/javase/specs/jls/se9/html/index.html

Kapitel 1 Einleitung

Es enthält nur Definitionen von Begriffen, die in Büchern verwendet werden. Du musst es nicht lesen. (Ende)

Kapitel 2 Erstellen und Verschwinden von Objekten

Punkt 1 Betrachten Sie eine statische Factory-Methode anstelle eines Konstruktors.

Zum Beispiel sieht es wie folgt aus.

• NG: BigInteger (int, int, Random) ← Konstruktor. Verwirrend.
• OK: BigInteger.probablePrime (int, Random) ← statische Factory-Methode. Einfach zu verstehen.

Betrachten Sie zuerst die statische Factory-Methode, und wählen Sie einen Konstruktor aus, wenn er subtil ist.

◆ Vorteile

** ① Sie können einen beschreibenden Namen angeben. ** ** **

Der Konstruktor hat die folgenden Unannehmlichkeiten.

• Der Name des Konstruktors ist auf eins beschränkt (Klassenname).

• Der einzige Unterschied zwischen Konstruktoren ist der Unterschied in den Argumenten. Infolgedessen ist es für Benutzer schwierig, die Unterschiede zwischen Konstruktoren zu verstehen.

Die statische Factory-Methode hat diese Unannehmlichkeit nicht.

** ② Es ist nicht erforderlich, ein neues Objekt zu erstellen. Verwenden Sie dasselbe Objekt erneut. ** ** **

** ③ Sie können ein Objekt dieses Subtyps anstelle des Rückgabetyps selbst zurückgeben. ** ** **

Beispielsweise verfügt java.util.Collections über eine statische Factory-Methode namens "emptyList ()". Es hat die folgenden Funktionen.

• emptyList () gibt eine Instanz der inneren Klasse EmptyList zurück. Die innere Klasse EmptyList ist nicht öffentlich und kann von außen ausgeblendet werden.
• Der Rückgabetyp von "emptyList ()" ist die "List" -Schnittstelle.

Dank dessen ist die Sammlungs-API sehr einfach. Speziell···

• Der Implementierer muss dem Benutzer nicht erklären, wie EmptyList (API) verwendet wird.

• Benutzer müssen sich der Existenz von EmptyList nicht bewusst sein und müssen nicht wissen, wie sie verwendet werden (API). Sie müssen nur wissen, wie Sie die "List" -Schnittstelle verwenden.

** ④ Sie können den zurückzugebenden Subtyp je nach Situation ändern. ** ** **

In ③ basiert die Erklärung auf der Annahme, dass immer derselbe Subtyp zurückgegeben wird. Was ich in ④ sagen möchte, ist, dass Sie aus mehreren Untertypen diejenige auswählen und zurückgeben können, die zu Ihrer Situation passt.

** ⑤ Der zurückzugebende Subtyp kann zur Laufzeit festgelegt werden. (Es ist in Ordnung, auch wenn zum Zeitpunkt der Implementierung der statischen Factory-Methode noch keine Entscheidung getroffen wurde.) **

Zum Beispiel entspricht JDBC "DriverManager.getConnection ()" diesem.

Dadurch wird es als API flexibler.

◆ Nachteile

** ① Der Benutzer kann keine Unterklasse des Rückgabetyps erstellen. ** ** **

Beispielsweise gibt emptyList () in java.util.Collections EmptyList zurück. Da EmptyList jedoch eine private Klasse ist, können Benutzer keine Unterklassen von EmptyList erstellen.

Ohne auf dieses Beispiel beschränkt zu sein, konnte ich mir keinen Fall vorstellen, der mich dazu bringen würde, eine Unterklasse zu erstellen. In der Praxis glaube ich nicht, dass es Schwächen oder Einschränkungen gibt.

** ② Für Benutzer ist es schwierig, statische Factory-Methoden zu finden. ** ** **

Dies ist sicherlich der Fall. In Javadoc ist der Konstruktor ein separater Abschnitt, der ihn hervorhebt, aber statische Factory-Methoden sind in der Liste der Methoden enthalten.

Versuchen Sie, die API für Benutzer verständlich zu machen, indem Sie den folgenden allgemeinen Namensmustern folgen.

Referenz

Übersicht über das Collections Framework https://docs.oracle.com/javase/jp/9/docs/api/java/util/doc-files/coll-overview.html

Punkt 2 Betrachten Sie einen Builder, wenn Sie mit vielen Konstruktorparametern konfrontiert sind

[NG] Teleskopmuster

public class NutritionFacts {
    //Felddefinition weggelassen

    public NutritionFacts(int servingSize, int servings) {
        this(servingSize, servings, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories) {
        this(servingSize, servings, calories, 0);
    }

    //Der obige Fluss geht endlos weiter ...
}

NG Punkt

• Auch wenn der Parameter für den Benutzer keine Rolle spielt, wird die Einstellung erzwungen.
• Der Benutzer muss sich Gedanken darüber machen, was ein Zahlenparameter ist, was sehr schwierig ist. (In der Praxis wird die IDE es ein wenig reduzieren)
• Für den Leser des Codes ist es schwierig, die Bedeutung der einzelnen Parameter zu verstehen. (In der Praxis wird die IDE es ein wenig reduzieren)
• Solange die Typen übereinstimmen, tritt kein Kompilierungsfehler auf. Selbst wenn Parameter desselben Typs in der falschen Reihenfolge angegeben werden, bemerkt der Benutzer den Fehler nicht.

[NG] Java Beans-Muster

//Es sind einfach nur Java Beans.
public class NutritionFacts {
    //Felddefinition weggelassen

    public NutritionFats() {}
    
    public void setServingSize(int val) { //Abkürzung}
    public void setServings(int val) { //Abkürzung}
    public void setCalories(int val) { //Abkürzung}
    //Der Setter fährt fort ...
}

NG Punkt

• Nach der Instanziierung können Inkonsistenzen zwischen Parametern auftreten. Ursprünglich sollten solche Inkonsistenzen vor der Instanziierung erkannt werden.
• Sie können den internen Status von Setter ändern, sodass Sie die Klasse nicht unveränderlich machen können.

[Builder-Muster]

//Benutzercode
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).
    calories(100).sodium(35).carbohydrate(27).build();

Vorteile

• Einfach zu implementieren.
• Leicht zu lesen.
• Sie können Inkonsistenzen zwischen Parametern erkennen, bevor Sie mit build () instanziieren. Dieser Vorteil ist sehr wichtig. Dies liegt daran, dass es schwierig ist, die Ursache zu identifizieren, wenn die Inkonsistenz hier nicht erkannt wird und an einer entfernten Stelle aufgrund der Inkonsistenz ein Fehler auftritt.
• Dieses Muster kann angewendet werden, auch wenn die Klassen hierarchisch sind.
• Macht die API flexibel. Sie können beispielsweise immer mehr eindeutige Objekte erstellen, indem Sie einen Builder (eine Instanz) wiederverwenden und die Seriennummer in "build ()" nummerieren.

Nachteile (trivial)

• Builder muss instanziiert werden und sollte in Situationen berücksichtigt werden, in denen hohe Leistungsanforderungen bestehen. Ich denke jedoch, dass eine solche Situation in der Praxis selten ist, daher ist sie ein kleiner Nachteil.
• Der Code des Benutzers ist länger als das Teleskopmuster. Daher ist es möglicherweise besser, es zu verwenden, wenn viele Parameter vorhanden sind. Die Anzahl der Parameter kann sich jedoch stetig erhöhen, wenn Sie sie beibehalten. Es ist unrealistisch, in der Mitte zum Builder-Muster zu wechseln, sodass dies ein geringfügiger Nachteil ist.

Punkt 3 Erzwingen Sie Singleton-Eigenschaften mit einem privaten Konstruktor oder einem Aufzählungstyp

Es gibt drei Möglichkeiten, einen Singleton zu erreichen. Wählen Sie die beste für Ihre Situation.

• Implementieren Sie Singleton mit Aufzählungstyp. ← In vielen Fällen ist dies das Beste
• Erstellen Sie eine Instanz mit dem privaten Konstruktor ...
• Auf öffentliches Feld setzen und veröffentlichen.
• Rückkehr mit statischer Factory-Methode.

Wenn Sie eine einzelne Tonne mit Aufzählungstyp implementieren, sieht dies folgendermaßen aus.

Aufzählungstyp einzelne Tonne

public enum Elvis {
    INSTANCE;
    public void someMethod();
}

Der beste Weg ist, enum zu verwenden, da andere Methoden das Risiko eingehen, keine einzige Tonne zu sein, und Sie müssen sie umgehen. Insbesondere ist es wie folgt.

• Im Fall eines privaten Konstruktors kann der Benutzer den internen privaten Konstruktor durch Reflektion aufrufen. Es ist mühsam, einen Überprüfungsprozess zu schreiben, um dies zu verhindern.
• Wenn Sie eine Singleton-Klasse serialisieren möchten, besteht das Risiko, dass Sie bei jeder Deserialisierung eine Instanz erstellen. Es ist mühsam, einen Prozess zu schreiben, um dies zu verhindern. (Ich denke, es ist selten, dass Sie serialisieren möchten ...)

Ich denke, dass diese Risiken in der Praxis ignoriert werden können, aber Sie sollten richtig darüber nachdenken.

Die Methode zur Verwendung des Aufzählungstyps wurde in der Praxis nicht gesehen, ist jedoch in den obigen Punkten rational und sollte aktiv angewendet werden.

Die beiden Methoden zur Verwendung des privaten Konstruktors bieten die folgenden Vorteile. Ich bin jedoch der Meinung, dass es nur eine begrenzte Anzahl von Fällen gibt, in denen Sie diese Vorteile erzielen möchten. Letztendlich ist enum in vielen Fällen die beste Wahl.

Punkt 4 Unmöglichkeit der Instanziierung mit privatem Konstruktor erzwingen

Eine Klasse, die nur aus statischen Methoden und statischen Feldern besteht, wird üblicherweise als Dienstprogrammklasse bezeichnet.

Solche Klassen sollten nicht instanziiert und verwendet werden, aber wenn der Konstruktor verwendet wird, können sie versehentlich instanziiert werden. Ich glaube nicht, dass es tatsächlich viel Schaden gibt, aber es macht mich sehr enttäuscht, wenn es auf diese Weise verwendet wird.

Implementieren wir also einen privaten Konstruktor wie folgt:

public class UtilityClass {
    //Unterdrücken Sie den Standardkonstruktor, damit er nicht instanziiert werden kann.
    //Indem wir einen Kommentar wie diesen hinterlassen, vermitteln wir der Nachwelt die Absicht, diesen Konstruktor zu implementieren.
    private UtilityClass() {
        throw new AssertionError();
    }
}

Dies verhindert, dass Sie versehentlich instanziiert oder versehentlich geerbt werden, um Unterklassen zu erstellen.

Punkt 5 Wählen Sie die Abhängigkeitsinjektion aus, anstatt Ressourcen direkt zu verknüpfen

Nehmen wir als Beispiel eine Rechtschreibprüfung.

[NG] Als Utility-Klasse implementiert

public class SpellChecker{
    //Wörterbuch für Speccheck
    private static final Lexicon dictionary = ...;

    //Unterdrücken Sie die Instanziierung gemäß der Methode von Punkt 4
    private SpellChecker() {} 

    public static boolean isValid(String word) { ... }
}

[NG] Implementiert als eine Tonne

// SpellChecker.INSTANCE.isValid("some-word");Verwenden Sie wie.
public class SpellChecker{
    //Wörterbuch für Speccheck
    private final Lexicon dictionary = ...;

    //Unterdrücken Sie die Instanziierung gemäß der Methode von Punkt 4
    private SpellChecker() {} 
    public static SpellChecker INSTANCE = new SpellChecker(...); 

    public static boolean isValid(String word) { ... }
}

Da in diesen NG-Beispielen nur ein Wörterbuch verwendet werden kann, ist es nicht möglich, die Wörterbücher je nach Situation zu wechseln. Diese Schwierigkeit betrifft nicht nur den Produktionscode, sondern auch das Testen.

Es gibt eine Möglichkeit, eine Methode wie "setDictionary (Lexikon)" bereitzustellen, damit Sie sie später ändern können, aber für den Benutzer ist sie schwer zu verstehen. Es ist auch nicht threadsicher.

Erstens bedeutet die Tatsache, dass sich das Wörterbuch je nach Situation ändert, dass das Wörterbuch ein "Zustand" ist. Daher sollten Sie die Rechtschreibprüfung als eine Klasse implementieren, die instanziiert und verwendet werden kann.

Insbesondere ist es wie folgt.

[OK] Im Stil der Abhängigkeitsinjektion implementiert

public class SpellChecker{
    //Wörterbuch für Speccheck
    private final Lexicon dictionary;

    //Da es einen "Status" hat, der als Wörterbuch bezeichnet wird, wird es instanziiert und verwendet.
    //Zu diesem Zeitpunkt wird eine Abhängigkeit namens Wörterbuch eingefügt.
    public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    } 

    public static boolean isValid(String word) { ... }
}

Auf diese Weise können Sie je nach Situation die Wörterbücher wechseln und es ist threadsicher.

Punkt 6 Vermeiden Sie unnötige Objekte

Durch die Wiederverwendung von Objekten können die Kosten für die Erstellung von Objekten minimiert und ihre Geschwindigkeit erhöht werden.

Wenn Sie dagegen viele unnötige Objekte erstellen, ist dies extrem langsam.

Die unveränderliche Natur ist sehr wichtig, da unveränderliche Objekte (unveränderliche Objekte) immer sicher wiederverwendet werden können.

[NG Teil 1]

// new String()Wir erstellen also ein unnötiges Objekt.
// "bikini"Wir erstellen also ein unnötiges Objekt.
String s = new String("bikini");

【OK】

//Das generierte Objekt ist"bikini"Nur String-Instanz.
//String-Literale innerhalb derselben JVM"bikini"Instanzen von werden immer wiederverwendet.
String s = "bikini";

[NG Teil 2]

//Da es sich um einen Konstruktor handelt, werden immer neue Objekte erstellt.
new Boolean(String);

【OK】

//Die statische Factory-Methode muss kein neues Objekt erstellen.
//Ein wahres oder falsches boolesches Objekt wird wiederverwendet.
Boolean.valueOf(String);

[NG Teil 3]

//Innerhalb von Übereinstimmungen wird ein Musterobjekt erstellt.
// isRomanNumeral()Bei jedem Aufruf wird ein Musterobjekt erstellt.
static boolean isRomanNumeral(String s){
    return s.matches("Reguläre Ausdrücke. Der Inhalt wird weggelassen.");
}

【OK】

public class RomanNumerals {
    //Sie verwenden ein Musterobjekt wieder.
    private static final Pattern ROMAN = Pattern.compile("Reguläre Ausdrücke. Der Inhalt wird weggelassen.");

    static boolean isRomanNumeral(String s) {
        return ROMAN.matcher(s).matches();
    }
}

[NG Teil 4]

//NG Beispiel im Auto Boxen
private static long sum() {
    Long sum = 0L;
    for (long i = 0; i <= Integer.MAX_VALUE; i++)
        //Da Long unveränderlich ist, wird bei jedem Hinzufügen eine neue Instanz erstellt.
        sum += i;

    return sum;
}

【OK】

private static long sum() {
    //Wechseln Sie zum primitiven Typ (Long)-> long）
    long sum = 0L;
    for (long i = 0; i <= Integer.MAX_VALUE; i++)
        sum += i;

    return sum;
}

Übrigens gibt Map.keySet () eine Set-Ansicht (Adapter) zurück, aber unabhängig davon, wie oft Sie keySet () aufrufen, wird dieselbe Set-Instanz zurückgegeben. Es ist leicht zu glauben, dass bei jedem Aufruf eine neue Instanz erstellt wird. Tatsächlich wird die Instanz jedoch auch an diesen Stellen wiederverwendet und die Effizienz verbessert. Selbst wenn wir die API implementieren, sollten wir sie unter dem Gesichtspunkt "Muss eine neue Instanz erstellt werden?" Optimal implementieren.

Punkt 7 Veraltete Objektreferenzen entfernen

Wenn Ihre Klasse einen eigenen Speicher verwaltet, der außerhalb der Kontrolle des Garbage Collectors liegt, müssen Sie die Verweise auf nicht mehr benötigte Objekte löschen (setzen Sie die Variable auf "null").

Nicht verwaltet bedeutet, dass der Garbage Collector nicht einmal ein praktisch nicht verwendetes Objekt erkennen kann.

Normalerweise unterliegen Variablen, die außerhalb des Gültigkeitsbereichs liegen, der Speicherbereinigung. Wenn Sie dagegen Objekte in einer Klasse verwalten, sind diese nicht außerhalb des Gültigkeitsbereichs und unterliegen keiner Speicherbereinigung. Aus Sicht des Garbage Collectors gilt das Objekt als in Gebrauch.

In diesem Buch wird das Obige anhand einer einfachen Stapelimplementierung als Beispiel erläutert. Weitere Informationen finden Sie im Buch.

Fall der Implementierung eines eigenen Caches

Selbst wenn Sie Ihren eigenen Cache implementieren, entspricht dies dem oben genannten "Fall der Verwaltung Ihres eigenen Speichers in der Klasse".

Wenn Sie beispielsweise Bilddaten mit HashMap zwischenspeichern, sollte HashMap als Feld eines Objekts A verwaltet werden, damit die Referenzen wie folgt verbunden sind.

Quelle-> Objekt A-> HashMap-> Schlüssel und Wert

Selbst wenn die von HashMap verwalteten Daten (Schlüssel und Wert) nicht mehr benötigt werden, werden diese Daten nicht als Müll gesammelt, solange weiterhin auf Objekt A und HashMap verwiesen wird. Infolgedessen wächst der Speicher.

Das Mittel in diesem Fall ist wie folgt. (Ich glaube nicht, dass es viele Möglichkeiten gibt, den Cache selbst zu implementieren ...)

** Methode ① Implementieren Sie den Cache mit WeakHashMap. ** ** **

Wenn ein Schlüssel nicht mehr von etwas anderem als seinem WeakHashMap-Objekt referenziert wird, unterliegt die WeakHashMap dem nächsten GC für diesen Eintrag (Schlüssel-Wert-Paar). Wir verwenden einen Mechanismus, der als schwache Referenz bezeichnet wird.

Wenn Sie den Schlüssel mit dem Status "Der Schlüssel wird nicht von einem anderen als diesem WeakHashMap-Objekt referenziert" aus dem Cache löschen möchten, sollten Sie ihn übernehmen.

Wie in diesem Buch erläutert, kann es nicht mehr als Cache bezeichnet werden, wenn es so einfach aus dem Cache gelöscht wird. Einzelheiten finden Sie unter [siehe unten. ](# Was ist eine Referenz schwache Referenz)

** Methode (2) Löschen Sie regelmäßig alte Daten im Cache mit ScheduledThreadPoolExecutor. ** ** **

Dieser Artikel wird empfohlen, um ein schnelles Verständnis der Verwendung von ScheduledThreadPoolExecutor zu erhalten. https://codechacha.com/ja/java-scheduled-thread-pool-executor/

Verwenden Sie es, wenn Sie etwas löschen möchten, das seit einiger Zeit im Cache registriert ist.

** Methode ③ Wenn Sie dem Cache einen neuen Eintrag hinzufügen, löschen Sie den alten. ** ** **

Es ist einfach. Wenn Sie ähnlich wie in (2) etwas löschen möchten, das seit einiger Zeit im Cache registriert ist, sollten Sie es übernehmen.

Fall der Registrierung von Listenern und Rückrufen im Speicher

Wenn Sie eine API erstellen, mit der Listener und Rückrufe vom Client registriert werden können, unterliegen die registrierten Listener und Rückrufe keiner GC, es sei denn, sie werden mit angemessener Berücksichtigung erstellt.

Es ist eine gute Idee, einen schwachen Referenzmechanismus zu verwenden, z. B. ihn als Schlüssel für WeakHashMap zu speichern. Wenn es von niemand anderem als WeakHashMap mehr verwendet wird, unterliegt es der GC.

Referenz: Was ist eine schwache Referenz?

Objekte, die normalerweise den Referrer nicht erreichen können (Objekte, die von niemandem verwendet werden), unterliegen der GC und werden aus dem Speicher gelöscht.

Es kann jedoch ein Problem sein, wenn es sofort gelöscht wird. Es gibt einen Mechanismus, der verhindert, dass Objekte, die von der Referenzquelle aus nicht erreicht werden können, sofort der GC unterliegen. Dies ist das java.lang.ref-Paket.

In der Welt dieses Pakets werden gewöhnliche Referenzen als "starke Referenzen" bezeichnet und ihre eigenen "Referenzen" wie folgt definiert.

Punkt 8 Vermeiden Sie Finalisierer und Reiniger

Der Finalizer hier ist java.lang.Object # finalize () oder eine Methode, die ihn in einer Unterklasse überschreibt.

Ein Reiniger ist ein java.lang.ref.Cleaner.

Es gibt verschiedene Gründe, warum dies nicht gut ist, aber es besteht fast keine Notwendigkeit, den Inhalt zu verstehen.

Verwenden Sie es niemals, da es sowieso gefährlich ist. Das ist gut.

Punkt 9 Wählen Sie "Try-with-Resources" und nicht "Try-finally"

try-finally hat folgende Probleme:

• Es ist wahrscheinlich, dass eine enge Leckage auftritt.
• Wenn Sie versuchen, ohne Auslassung zu schließen, wird die Verschachtelung erhöht. Infolgedessen ist der Code schwer zu lesen und schwer zu ändern.
• Einfach, die auftretenden Ausnahmen zu zerstören.
• Um Ausnahmen zu vermeiden, müssen Sie eine catch-Klausel schreiben. Infolgedessen ist der Code schwer zu lesen und schwer zu ändern.

Try-with-Resources löst diese Probleme.

Wenn während des Versuchs eine Ausnahme auftritt und dann auch beim Schließen eine Ausnahme auftritt, wird der ersteren Priorität eingeräumt und ausgelöst. Sie können dies in der catfh-Klausel abfangen.

Verwenden Sie für den Zugriff auf Letzteres die Methode getSuppressed im ersteren Ausnahmeobjekt. In vielen Fällen möchten Sie jedoch das erstere kennenlernen, sodass Sie anscheinend nicht viele Möglichkeiten haben, es zu verwenden.

Kapitel 3 Allen Objekten gemeinsame Methoden

Punkt 10 Befolgen Sie bei allgemeinen Überschreibungen den allgemeinen Vertrag

Ich denke, die Möglichkeit, die Equals-Methode zu überschreiben, ist in erster Linie begrenzt. Wenn Sie überschreiben möchten, müssen die Anforderungen erfüllt werden.

Wenn Sie die Methode equals überschreiben müssen, halten Sie sich an diese Anforderung. Insbesondere sind die Anforderungen wie folgt.

• Reflexionsvermögen: x.equals (x) gibt true zurück.

• Symmetrie: x.equals (y) gibt nur dann true zurück, wenn y.equals (x) true ist.

• Übergang: Wenn x.equals (y) und y.equals (z) wahr sind, gibt x.equals (z) true zurück.

• Konsistenz: Wenn x.equals (y) mehrmals aufgerufen wird, ist das Ergebnis dasselbe.

• Nicht null: x.equals (null) gibt false zurück.

• X, y, z sind nicht null.

Das Buch sagt, dass es bei jeder Anforderung einige Dinge zu beachten gibt, aber es gibt nicht viele Möglichkeiten, Gleichheit zu überschreiben. Daher ist es wahrscheinlich weniger kostspielig, mehr zu lernen, wenn Sie es nicht benötigen.

Aus diesem Grund beziehe ich mich nur dann auf Bücher, wenn ich sie brauche, und ich werde auch in diesem Artikel nicht ins Detail gehen.

Punkt 11 Wenn Sie überschreiben gleich überschreiben, überschreiben Sie immer hashCode

Wie Sie in Punkt 10 sehen können, gibt es nicht viele Chancen, Gleichheit zu überschreiben, daher scheint dieser Punkt auch nicht sehr wichtig zu sein. Ich gebe Ihnen nur einen Überblick.

Die Anforderungen zum Überschreiben der hashCode-Methode lauten wie folgt:

• Wenn die hashCode-Methode mehrmals aufgerufen wird, gibt sie denselben Wert zurück.
• Wenn die beiden Objekte in der Methode equals gleich sind, gibt die hashCode-Methode der beiden Objekte denselben Wert zurück.
• Nur weil sich die beiden Objekte in der Methode equals unterscheiden, muss die hashCode-Methode der beiden Objekte keine unterschiedlichen Werte zurückgeben **. Es ist jedoch einfacher, die Leistung der Hash-Tabelle zu verbessern, indem unterschiedliche Werte zurückgegeben werden.

Punkt 12 Überschreiben Sie immer toString

Das Überschreiben der toString-Methode hat den Vorteil, dass Benutzer dieser Klasse das Debuggen erleichtern können.

Das in der Praxis geschaffene System ist jedoch kein Kunstwerk, und die personellen und zeitlichen Ressourcen sind begrenzt. Daher denke ich, dass Sie entscheiden sollten, ob Sie bei Bedarf überschreiben möchten oder nicht.

Beachten Sie Folgendes, wenn Sie die toString-Methode überschreiben:

• Geben Sie alle Informationen aus, die der Benutzer kennen sollte. Beachten Sie, dass toString für Sie existiert.
• Entscheiden Sie je nach Situation, ob Sie das Format des Rückgabewerts festlegen möchten (z. B. 090-1234-5678 für Telefonnummern). Es mag für Benutzer schön sein, ein festes Format zu haben, aber sobald es entschieden ist, ist es schwierig, es später zu ändern. Lassen Sie uns balancieren.

Punkt 13 Klon vorsichtig überschreiben

Das Überschreiben von Object.clone () ist im Grunde NG. Der Grund ist wie folgt.

• Die Anforderungen, die beim Überschreiben erfüllt werden müssen, werden vom Compiler weder erzwungen noch im Javadoc angegeben.
• Die Anforderungen sind sehr komplex. Einzelheiten finden Sie im Buch.
• Für die überschriebene Methode müssen Sie Object.clone () in der Form super.clone () aufrufen. Zu diesem Zeitpunkt wird die folgende Komplexität erzeugt.
• Sie müssen eine CloneNotSupportedException behandeln, die Object.clone () möglicherweise auslöst.
• Der Rückgabetyp von Object.clone () ist Object. In der Praxis müssen Sie ihn jedoch in einen bestimmten Typ umwandeln.
• Endgültige Felder können nicht kopiert werden, da Änderungen verboten sind. Sie müssen final aus einem nicht wesentlichen Grund entfernen, um clone () zu überschreiben.
• Neben den oben genannten Gründen gibt es noch weitere detaillierte Gründe. Einzelheiten finden Sie im Buch.

Da es sich um NG handelt, sollten Sie Object.clone () nicht überschreiben, es sei denn, Sie haben bereits eine Klasse, die Object.clone () überschreibt, und müssen diese bei der Wartung beheben.

Verwenden Sie stattdessen die folgenden Methoden. Diese haben die oben genannten Nachteile nicht.

//Konstruktor kopieren
public Yum(Yum yum) { ... }

//Fabrik kopieren
public static Yum newInstance(Yum yum) { ... }

Unabhängig davon, ob Sie einen Kopierkonstruktor oder eine Kopierfactory-Methode oder Object.clone () verwenden, sollten Sie die folgenden Punkte gemeinsam beachten.

• Erstellen Sie beim Kopieren eines Felds in der Regel eine tiefe Kopie.

Mit anderen Worten, beim Kopieren eines Felds reicht es nicht aus, die Referenz des Kopierquellenobjekts auf das Kopierzielfeld festzulegen. Dies liegt daran, dass dieselbe Objektreferenz zwischen der Kopierquelle und dem Kopierziel geteilt wird. Dies ist die sogenannte flache Kopie. Die Idee ist offensichtlich, aber die Implementierung ist ziemlich umständlich. Es gibt eine Ausnahme von dieser Regel. Wenn es sich um ein unveränderliches Objekt handelt, können Sie die Referenz kopieren.

• Natürlich ändert sich der Status der Kopierquelle während des Kopierens nicht, also implementieren wir ihn in thread safe.

Um diesen Artikel zu verstehen, empfehlen wir Ihnen, Folgendes im Voraus zu kennen.

• Object.clone () verfügt über einen nativen Modifikator und ist daher in anderen Sprachen als Java implementiert. Mit anderen Worten, es gibt den Inhalt des Prozesses.

• Kovarianter Rückgabetyp https://www.slideshare.net/ryotamurohoshi/ss-38240061

Punkt 14 Erwägen Sie die Implementierung von Comparable

Durch Implementieren von Comparable.compareTo () in der von Ihnen entwickelten Klasse können Sie die Objekte dieser Klasse in einer Sammlung speichern und die praktische API der Sammlung verwenden. Zum Beispiel können Sie gut sortieren.

Wenn Sie diesen Vorteil nutzen möchten, implementieren Sie eine vergleichbare Schnittstelle.

In diesem Fall müssen Anforderungen erfüllt sein, die dem Überschreiben der Equals-Methode ähneln.

• sgn (x.compareTo (y)) == -sgn (y.compareTo (x)). Das heißt, wenn die Reihenfolge umgekehrt und der Vergleich durchgeführt wird, wird auch das Vorzeichen des Ergebnisses umgekehrt.

• Wenn (x.compareTo (y)> 0 && y.compareTo (z)> 0), dann ist x.compareTo (z)> 0. Mit anderen Worten, es wird eine Übergangsbeziehung.

• Wenn x.compareTo (y) == 0 ist, dann ist sgn (x.compareTo (z)) == sgn (y.compareTo (y)). Das heißt, wenn die Reihenfolge von x und y gleich ist, ist das Ergebnis gleich, wenn andere Objekte z mit jedem von x und y verglichen werden.

• Wenn x.compareTo (y) == 0 ist, dann ist x.equals (y) wahr und umgekehrt ** ist nicht erforderlich, aber vorzuziehen **.

• Sgn (Ausdruck) ist eine Funktion, die -1, 0, 1 zurückgibt, wenn der Ausdruck negativ, null bzw. positiv ist.

Es gibt Hinweise zu den ersten drei Anforderungen. Bei einer vorhandenen Klasse, die Comparable implementiert, ist es praktisch unmöglich, diese Anforderungen zu erfüllen, wenn Sie sie erweitern und neue Felder hinzufügen. Wenn Sie es erzwingen, ist es kein objektorientierter Code mehr. Lassen Sie es uns in einem solchen Fall mit Komposition statt mit Erweiterung realisieren (Punkt 18).

Was ist, wenn wir die vierte Anforderung verletzen? Ein Beispiel für eine Verletzung ist Big Decimal. new BigDecimal ("1.0") und new BigDecimal ("1.00") sind in der equals-Methode nicht gleich und in der compareTo-Methode gleich.

Wenn Sie sie in ein neues HashSet einfügen, werden sie mit der Methode equiqls verglichen, sodass die Anzahl der Elemente 2 beträgt. Wenn Sie es dagegen in ein neues TreeSet einfügen, beträgt die Anzahl der Elemente 1, da es mit der compareTo-Methode verglichen wird. Wenn Sie dieses Verhalten nicht berücksichtigen, wissen Sie nicht, was die Ursache für den unwahrscheinlichen Fall eines Problems ist.

Beachten Sie zusätzlich zu den vier Anforderungen Folgendes:

• Die Schnittstelle Comparable ist parametrisiert, sodass keine Argumenttypen überprüft oder umgewandelt werden müssen.
• Wenn das Argument null ist, sollte eine NullPointerException ausgelöst werden. Dies sollte normalerweise der Fall sein, ohne etwas zu tun.
• Wenn das Feld, das Sie vergleichen, ein Objekt ist, vergleichen Sie sie mit compareTo, anstatt ihre Referenzen zu vergleichen. Wenn Sie möchten, können Sie compareTo selbst implementieren oder einen vorhandenen Comparator verwenden (z. B. String.CASE_INSENSITIVE_ORDER).
• Verwenden Sie beim Vergleichen von Größen keine Vergleichsoperatoren (>, <, ==). Es wird nur verwirrend. Verwenden Sie stattdessen eine Vergleichsmethode wie Integer.compare ().
• In Java 8 kann es mithilfe der Komparator-Konstruktionsmethode fließend implementiert werden.

private static final Comparator<PhoneNumber> COMPARATOR = 
            comparingInt((PhoneNumber pn) -> pn.areaCode)
                .thenComparingInt(pn -> pn.prefix)
                .thenComparingInt(pn -> pn.lineNum);

public int compareTo(PhoneNumber pn) {
    return COMPARATOR.compare(this, pn);
}

• Wenn ein auf der Differenz basierender Komparator verwendet wird, kann nicht nur die Übergangsanforderung nicht erfüllt werden, sondern es besteht auch das Risiko, dass ein ganzzahliger Überlauf auftritt. Verwenden Sie stattdessen statische Methoden wie Integer.compare () oder Vergleichskonstruktionsmethoden.

//NG Beispiel
static Comparator<Object> hashCodeOrder = new Comparator<>() {
    public int compare(Object o1, Object o2) {
        return o1.hashCode() - o2.hashCode();
    }
}

Kapitel 4 Klassen und Schnittstellen

Punkt 15 Minimieren Sie die Zugänglichkeit für Klassen und Mitglieder

Was ist das Verstecken und Einkapseln von Informationen?

Minimieren Sie den Teil der Komponente, auf den von außen zugegriffen werden kann (öffentliche API). Machen Sie andere Teile (interne Daten, Implementierungsdetails) von außen unzugänglich.

Um es klar auszudrücken, halten Sie das, was Sie öffentlich oder geschützt erklären, auf ein Minimum. Gestalten Sie Ihre Klasse sorgfältig dafür.

Gründe für das Ausblenden und Einkapseln von Informationen (warum)

Durch das Ausblenden und Einkapseln von Informationen können Komponenten individuell entwickelt und individuell optimiert werden. Mit anderen Worten, Sie können die Sorge, dass andere Komponenten nicht beschädigt werden, erheblich reduzieren.

Der Zweck des Versteckens und Einkapselens von Informationen besteht darin, Folgendes zu erreichen.

• Ermöglicht die parallele Entwicklung jeder Komponente, um die Entwicklung zu beschleunigen.
• Reduziert den Aufwand für die Aufpralluntersuchung und reduziert die Wartungslast.
• Ermöglicht die lokale Beseitigung von Engpässen, um die Leistungsoptimierung zu erleichtern.
• Ermöglicht die Wiederverwendung von Komponenten.

Wenn Sie diese Ziele nicht erreichen können, macht es keinen Sinn, Informationen auszublenden oder zu kapseln. Praktische Programme sind keine Kunstwerke, sondern ein Mittel für ein erfolgreiches Geschäft. Sie sollten also nicht zufrieden sein, dass Sie etwas Schönes gemacht haben (ich bin sehr vorsichtig, weil es einfach ist, auf diese Weise zufrieden zu sein).

Wie es geht (wie)

Beachten Sie insbesondere die folgenden Punkte.

• Anstatt die Öffentlichkeit ohne nachzudenken hinzuzufügen, wählen Sie diejenige, die die Zugänglichkeit minimiert.
• Durch die effektive Implementierung von Serializable wird es zu einer öffentlichen API.
• Als geschützt deklarierte APIs sind öffentliche APIs, da Benutzer (Unterklassen) auf sie zugreifen können.
• Das Paket zum Testen privat zu machen ist akzeptabel, da es nicht der Außenwelt ausgesetzt ist.
• Wenn Sie eine Konstante in public static final veröffentlichen, sollten Sie sicherstellen, dass die Konstante mit der Richtlinienabstraktionsrichtlinie übereinstimmt.
• Variable Objekte können vom Benutzer geändert werden. Daher ist es NG, als Konstante zu veröffentlichen. Stattdessen sollten Sie es entweder in ein unveränderliches Objekt konvertieren und veröffentlichen (z. B. Collections.unmodizableList) oder eine Kopie zurückgeben.
• Das in Java 9 hinzugefügte Modulsystem ist noch nicht weit verbreitet und seine Nützlichkeit wurde nicht bestätigt. Daher ist es derzeit nicht erforderlich, es aktiv zu verwenden.

Punkt 16 Verwenden Sie in der öffentlichen Klasse die Zugriffsmethode anstelle des öffentlichen Felds.

Es ist selbstverständlich, Setter / Getter hinzuzufügen.

In der Praxis halte ich es für vernünftig, dies zu tun, und ich denke, es ist einfach, Setter / Getter hinzuzufügen, ohne an irgendetwas zu denken. Wenn Sie den Grund jedoch nicht verstehen, ist dies kein gutes Klassendesign. Lassen Sie uns den Grund verstehen, warum wir Setter / Getter erneut hinzufügen sollten.

Der Grund für das Hinzufügen von Setter / Getter besteht darin, dass Informationen ausgeblendet und gekapselt werden. Insbesondere ist es wie folgt.

• Dies ist so, dass das Darstellungsformat der internen Daten (welcher Typ es sein sollte usw.) später geändert werden kann.
• Auf diese Weise können Sie die Konsistenz zwischen Feldern überprüfen.
• Dies ist so, dass die Hilfsverarbeitung später hinzugefügt werden kann.

Da der wesentliche Punkt darin besteht, die Anzahl der öffentlichen APIs so weit wie möglich zu reduzieren, besteht wenig Bedarf, Setter / Getter in den Feldern für paketprivate Klassen und private innere Klassen vorzubereiten. Wenn Sie versuchen, Setter / Getter unnötig bereitzustellen, dauert die Implementierung länger und der Code ist schwer zu lesen. Fühlen Sie sich nicht wie "nur Setter / Getter hinzufügen, ohne nachzudenken".

Punkt 17 Variabilität minimieren

Unveränderliche Objekte (unveränderliche Objekte) haben mehrere Vorteile, einschließlich der Tatsache, dass sie threadsicher verwendet werden können. Typische Beispiele in JDK sind grundlegende Datenklassen wie String, Integer, BigDecimal, BigInteger.

Wenn Sie eine eigene Klasse mit Werten erstellen, machen Sie diese unveränderlich, es sei denn, Sie haben einen guten Grund, sie variabel zu machen. Auch wenn es nicht praktisch ist, es perfekt unveränderlich zu machen, ist es eine gute Idee, es so unveränderlich wie möglich zu machen, beispielsweise das Feld so endgültig wie möglich zu machen. Dies liegt daran, dass es Vorteile wie weniger Probleme gibt, wenn die Anzahl möglicher Zustände verringert wird.

Vorteile von unveränderlichen Objekten

• Thread sicher. Es spielt keine Rolle, ob mehrere Threads darauf zugreifen. In der Praxis halte ich dies für den größten Verdienst.
• Der Benutzer muss den Statusübergang innerhalb des Objekts nicht kennen.
• Sie können die Instanz freigeben. Infolgedessen können die Kosten für das Erstellen von Objekten und der Speicherverbrauch reduziert werden.
• Der interne Status kann von Instanzen gemeinsam genutzt werden. Beispielsweise kann eine Klasse, in der sich ein Array befindet, einen Verweis auf ein von einer Instanz gehaltenes Array zur Wiederverwendung an eine neue Instanz übergeben.
• Andere Objekte, die diese Instanz in einem Feld enthalten, müssen möglicherweise intern einen bestimmten Status beibehalten (z. B. die Größenbeziehung zwischen Feldern). Wenn die im Feld gespeicherte Instanz variabel ist, wird der Prozess zum Beibehalten des gewünschten Status sehr kompliziert, da Sie den Statusübergang dieser Instanz kennen müssen. Oder es ist überhaupt nicht zu realisieren. Wenn umgekehrt die im Feld gehaltene Instanz unveränderlich ist, gibt es kein solches Problem.
• Es liegt eine Fehleratomizität vor. Die Fehleratomizität ist die Eigenschaft eines Objekts, in seinen Zustand vor dem Ausfall zurückzukehren. Unveränderliche Objekte ändern sich nicht in erster Linie, daher ist es natürlich, diese Eigenschaft zu haben. Um dem variablen Objektfehler Atomizität zu verleihen, ist Zeit und Mühe erforderlich. Unveränderliche Objekte erfordern keine solche Anstrengung, aber das ist gut so.

Nachteile unveränderlicher Objekte

• Jede Instanz mit einem anderen Wert verbraucht Systemressourcen. Infolgedessen kann es viel Speicher verbrauchen und zu einer schlechten Leistung führen. Beispielsweise kann in jedem von mehreren Berechnungsschritten eine Ad-hoc-Instanz erstellt und zerstört werden. Die Problemumgehung lautet wie folgt.

• Kombinieren Sie mehrere Verarbeitungsschritte in einer öffentlichen API.

• Stellt eine Begleitklasse für öffentliche Variablen bereit, z. B. StringBuilder für String.

Wie man ein unveränderliches Objekt herstellt (Anforderungen müssen erfüllt sein)

• Geben Sie keine Methoden an, die den Status eines Objekts ändern können, z. B. Setter.
• Verhindern Sie, dass es verlängert wird. Machen Sie die Klasse entweder endgültig oder machen Sie den Konstruktor privat und stellen Sie statische Factory-Methoden bereit.
• Machen Sie alle Felder endgültig. Dies macht das Feld unveränderlich und ermöglicht es Ihnen, Instanzreferenzen sicher zwischen Threads zu übergeben. Hiervon gibt es Ausnahmen. In einigen Fällen möchten Sie möglicherweise die Berechnungsergebnisse zwischenspeichern, die nur intern im Feld verwendet werden. In diesem Fall ist die Option, es nicht endgültig zu machen, auch eine Ameise.
• Machen Sie alle Felder privat. Auf diese Weise können Sie verhindern, dass der Benutzer den Inhalt des Objekts ändert, selbst wenn Sie ein variables Objekt im Feld haben. Sie können die interne Darstellung des Felds auch später ändern, ohne den Benutzer zu beeinträchtigen.
• Wenn das Feld ein veränderbares Objekt enthält, kann nur die unveränderliche Klasse (self) auf das veränderbare Objekt zugreifen. Verwenden Sie beim Erstellen eines unveränderlichen Klassenobjekts basierend auf dem vom Benutzer übergebenen Objekt nicht die Referenz, wie sie ist, sondern erstellen Sie eine defensive Kopie (Element 50).

Punkt 18 Wählen Sie Komposition statt Vererbung

Durch Vererbung wird die Kapselung unterbrochen. Mit anderen Worten, Unterklassen hängen von den Implementierungsdetails von Oberklassen ab. Infolgedessen können Änderungen in den Implementierungsdetails von Oberklassen dazu führen, dass Unterklassen nicht wie beabsichtigt funktionieren, oder zu Sicherheitslücken.

Sie könnten denken, dass es in Ordnung ist, wenn die Unterklasse die Methoden der Oberklasse nicht überschreibt, aber das ist nicht der Fall. Die Signatur einer Methode, die die später hinzugefügte Oberklasse enthält, kann mit der in der Unterklasse implementierten Methode in Konflikt stehen.

Springen Sie wegen dieser Unannehmlichkeiten nicht plötzlich in die Vererbung. Kompositionen haben nicht die gleichen Unannehmlichkeiten.

Die Vererbung ist jedoch zu 100% schlecht und die Zusammensetzung nicht zu 100% positiv. Lassen Sie uns je nach Situation zwischen Komposition und Vererbung wählen.

Was ist Zusammensetzung?

Anstatt eine vorhandene Klasse zu erben, behalten Sie die vorhandene Klasse in einem privaten Feld, wie unten gezeigt. Erweitern Sie eine vorhandene Klasse, indem Sie die Methoden dieser vorhandenen Klasse aufrufen.

//Klasse übertragen. Die Komposition wurde in dieser Klasse angewendet.
//Eine Klasse wird separat vom InstrumentedSet bereitgestellt, damit sie wiederverwendet werden kann.
public class ForwardingSet<E> implements Set<E> {
    //Halten Sie das Objekt der vorhandenen Klasse, die Sie erweitern möchten, in das Feld.
    private final Set<E> s;

    public ForwardingSet(Set<E> s) {
        this.s = s;
    }

    //Werfen Sie den Prozess auf das Objekt der vorhandenen Klasse, die Sie erweitern möchten.
    public void clear() {
        this.s.clear();
    }

    //Danach weggelassen.
}

/*
Erstellen Sie Ihre eigene Klasse, indem Sie die Übertragungsklasse erben.
Sie könnten denken: "Was? Vererbung ist nicht gut, oder?", Aber Vererbung hier ist
Dies ist eine vernünftige Entscheidung, um das Weiterleitungsset für andere Zwecke wiederverwendbar zu machen.
*/
public class InstrumentedSet<E> extends FowardingSet<E> {
    //Diese Klasse ist dafür verantwortlich, zu verwalten, wie oft ein Satz insgesamt hinzugefügt wurde.
    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {
        super(s);
    }

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    //Danach weggelassen.
}

Übrigens ist die Technik im obigen Codebeispiel nicht genau "Delegierung". Bitte seien Sie vorsichtig.

Wenn es in Ordnung ist zu erben

Sie können in den folgenden Fällen erben.

• Wenn die geerbte Klasse (die Klasse, die Sie eine Superklasse sein möchten) unter der Annahme erstellt wird, dass sie vererbt wird. Der Javadoc für Ihre Klasse sollte es sagen.
• Wenn die geerbte Klasse (Klasse, die Sie eine Superklasse sein möchten) nur im Paket veröffentlicht wird (Paket privat). In diesem Fall bleibt der nachteilige Effekt in der Verpackung, wenn Sie die Oberklasse ändern, auch wenn die Unterklasse nachteilig beeinflusst wird. Sie können Dinge erledigen, indem Sie die Unterklassen ändern.

Als wichtige Voraussetzung für die Übernahme der Vererbung ist es erforderlich, dass eine "is-a" -Beziehung zwischen den Klassen hergestellt wird. Das heißt, wenn Klasse B von Klasse A erbt, muss die Antwort "Sind alle Bs A?" Ja sein. Vererbung ist eine Technik zum Realisieren solcher Beziehungen im Code.

Punkt 19 Entwurf und Dokument für die Vererbung, andernfalls die Vererbung verbieten

Das Erstellen einer Klasse, die vererbt werden soll, ist tatsächlich äußerst schwierig und schwierig. Insbesondere sollten die folgenden Punkte berücksichtigt werden.

• Dem Benutzer muss angezeigt werden, wann die Methode, die in der Unterklasse überschrieben werden kann, in der Oberklasse aufgerufen wird. Diese Informationen sind genau die "Implementierungsdetails" der Oberklasse, sodass das Verstecken / Einkapseln von Informationen unterbrochen wird ...

• Sie müssen in Ihrer Oberklasse eine geschützte Methode (oder in einigen Fällen ein Feld) angeben, um Unterklassen Hooks für das interne Verhalten der Oberklasse bereitzustellen. Zu viel wird Sie von den Vorteilen des Versteckens / Einkapselens von Informationen abbringen. Andererseits erschweren zu wenige die Verwendung von Oberklassen für Unterklassen. Es ist äußerst schwierig, mit dieser Waage zu entwerfen.

• Superklassenkonstruktoren dürfen keine überschreibbaren Methoden aufrufen. Dies liegt daran, dass der Oberklassenkonstruktor am Anfang des Unterklassenkonstruktors aufgerufen wird. Sie rufen daher die überschreibbare Methode auf, wenn die Unterklasse nicht bereit ist.

• Es gibt einige Dinge zu beachten, wenn Superklassen Cloneable, Serializable implementieren. Ich denke jedoch, dass eine solche Situation selten ist, daher werde ich die Erklärung weglassen. Einzelheiten finden Sie im Buch.

Wie Sie sehen können, ist es extrem schwierig. Wenn Sie eine Klasse erstellen, die auf jeden Fall vererbt werden soll, sollten Sie bereit sein, die oben genannten Punkte zu übernehmen. Das ist ein Profi.

Ich denke, es gibt mehr Fälle, in denen dies nicht der Fall ist, als beim Erstellen einer Klasse, die vererbt werden soll. In diesem Fall machen Sie entweder die Klasse final oder machen Sie den Konstruktor privat und bereiten Sie eine statische Factory-Methode vor, damit die erstellte Klasse nicht versehentlich vererbt wird.

Punkt 20 Wählen Sie eine Schnittstelle über einer abstrakten Klasse aus

Dieser Artikel ist extrem schwer zu lesen. Ich werde vorrangig die Verständlichkeit erläutern.

Es gibt mehrere Implementierungen eines "Typs". Beispielsweise gibt es mehrere Implementierungen eines "Typs" namens "Vergleichbar". Java bietet die folgenden zwei Mechanismen, um einen solchen Typ "Mehrfachimplementierungen zulassen" zu realisieren.

• Schnittstelle (Klicken Sie hier für das Beispiel von Comparable)
• Abstrakte Klasse

Wenn Sie einen neuen Typ erstellen möchten, der "mehrere Implementierungen zulässt", tun Sie dies grundsätzlich mit einer Schnittstelle. Die Schnittstelle ist der abstrakten Klasse auf folgende Weise überlegen: Es ist einfach für Benutzer zu verwenden.

• Benutzer können mehrere Schnittstellen implementieren. Java kann nur eine Klasse erben, daher erhalten Sie diese Vorteile nicht, wenn Sie abstrakte Klassen verwenden.
• Benutzer können Schnittstellen zu einer vorhandenen Klasse einführen, auch wenn diese bereits etwas erbt. Java kann nur eine Klasse erben, daher erhalten Sie diese Vorteile nicht, wenn Sie abstrakte Klassen verwenden.
• Benutzer können vorhandene Schnittstellen kombinieren, um neue zu erstellen. Sie können dasselbe mit abstrakten Klassen tun, aber es ist lächerlich kompliziert. Insbesondere dieser Artikel ist sehr hilfreich.
• Angenommen, ein Benutzer möchte eine neue Funktion erstellen, indem er den vorhandenen Typ "Mehrere Implementierungen zulassen" verwendet. Wenn der Typ eine abstrakte Klasse ist, hat der Benutzer keine andere Wahl, als von der abstrakten Klasse zu erben. Wenn es sich um eine Schnittstelle handelt, können Sie die Komposition verwenden (Punkt 18).

Techniken zum Erstellen komplizierter Schnittstellen "Montagehilfe" "Skelettmontage"

Wenn Sie selbst eine einfache Benutzeroberfläche erstellen möchten, müssen Sie sich über diese Technik keine Gedanken machen. Bitte sehen Sie nur diejenigen, die es brauchen.

Angenommen, Sie erstellen beim Erstellen Ihrer eigenen Schnittstelle mehrere Methoden für diese Schnittstelle. Angenommen, Sie definieren Methode A und Methode B. Wenn Sie wissen, dass Methode A Methode B aufruft, ist es normalerweise einfacher, die typische Logik von Methode A in Ihrer Schnittstelle zu implementieren. Für Benutzer ist es einfacher, wenn sie nur wenige Teile implementieren.

Es gibt die folgenden zwei Muster, um dies zu erreichen.

• Unterstützung: Deklarieren Sie die Schnittstellenmethode standardmäßig und implementieren Sie die Logik in der Schnittstelle. Fügen Sie im vorherigen Beispiel dem Deklarationsteil von Methode A einen Standard hinzu, um die Logik zu implementieren. Die Standardeinstellung ist in Java 8 verfügbar. Wenn dies alles ist, was Sie tun müssen, erhalten Sie die vollen Vorteile der obigen Schnittstelle. Ziehen Sie diese Option also zuerst in Betracht, anstatt die unten gezeigte Skeleton-Implementierung.
• Skelettimplementierung: Eine Schnittstelle mit Implementierungsunterstützung wird in einer abstrakten Klasse implementiert. Es gibt einige Einschränkungen, z. B. dass Methoden der Object-Klasse nicht implementiert werden können, z. B. equals in der Standardschnittstelle. Sie können diese Teile mit einer abstrakten Klasse abdecken (implementieren). Ein konkretes Beispiel für dieses Muster ist AbstractList. Da davon ausgegangen wird, dass es vererbt wird, schreiben wir Javadoc außerdem fest gemäß Punkt 19.

Punkt 21 Entwerfen Sie die Schnittstelle für die Zukunft

Sobald die Schnittstelle veröffentlicht ist, ist es die letzte. Es ist nicht so einfach zu ändern. Lassen Sie es uns vor der Veröffentlichung gründlich überprüfen.

Wenn Sie einer Schnittstelle später eine Methode hinzufügen, wird bei der Klasse, die diese Schnittstelle implementiert, ein Kompilierungsfehler angezeigt. Sie können die Standardeinstellung als "Trick" verwenden, um dieses Problem zu vermeiden. In den folgenden Punkten ist dies jedoch NG. Es ist wichtig, sich nicht auf die Standardeinstellungen zu verlassen, sondern fest zu entwerfen.

• Standard existiert zu diesem Zweck nicht.
• Wenn die Standardmethode eine vorhandene Methode der Schnittstelle aufruft, wird möglicherweise der interne Status der Klasse unterbrochen, die die Schnittstelle implementiert hat. Es fühlt sich so an, als wäre die Site verwirrt, weil einseitige Regeln einseitig auferlegt werden, ohne die Situation auf der Site zu verstehen.

Punkt 22 Verwenden Sie die Schnittstelle nur, um den Typ zu definieren

Es gibt eine Methode zum Definieren einer Konstante in einer Schnittstelle und zum Implementieren dieser Schnittstelle, damit die Klasse die Konstante verwenden kann. Das ist NG. Das JDK hat tatsächlich eine solche Schnittstelle, aber Sie sollten sie nicht kopieren.

Dies liegt daran, dass die Klasse die Konstanten anderer Komponenten verwendet, was ein Implementierungsdetail darstellt. Das Implementieren einer Schnittstelle bedeutet, diesen Teil zu einer öffentlichen API zu machen. Implementierungsdetails sollten keine öffentlichen APIs sein. Erstens kommt das Offenlegen von Konstanten nicht in Frage, da es weit vom Wesen der Schnittstelle entfernt ist.

Wenn Sie die Konstante nach außen bereitstellen möchten, führen Sie einen der folgenden Schritte aus.

• Wenn eine Konstante stark an eine bestimmte Klasse gebunden ist, fügen Sie die Konstante innerhalb dieser Klasse hinzu. Zum Beispiel Integer.MAX_VALUE.
• Wenn eine Konstante als Mitglied eines Aufzählungstyps betrachtet wird, definieren Sie sie als Aufzählungstyp.
• In anderen Fällen definieren Sie es in einer Dienstprogrammklasse, die nicht instanziiert werden kann.

//Nicht unveränderliche Gebrauchsklasse
public class PhysicalConstatns(){
    private PhysicalConstants() {} //Instanziierung verhindern

    public static final double AVOGADROS_NUMBER = 6.022_140_857e23;
}

Durch das statische Importieren der Konstantenklasse muss der Benutzer den Klassennamen nicht jedes Mal schreiben, wenn die Konstante verwendet wird. Es wird im Buch erklärt, aber wenn Sie später darauf zurückblicken, werden Sie gefragt: "Wo ist diese Konstante definiert?", Was schwierig zu lesen sein kann. Berücksichtigen Sie das Gleichgewicht, wenn Sie entscheiden, ob ein statischer Import angemessen ist.

Punkt 23 Wählen Sie eine Klassenhierarchie anstelle einer markierten Klasse aus

Angenommen, es gibt eine Klasse in einer Klasse, die ausdrückt, ob es sich um einen Kreis oder ein Rechteck handelt. Einige von ihnen sind Konstruktoren, Felder und Methoden, die für Kreise verwendet werden, andere auch für Rechtecke.

Klassen, die auf diese Weise versuchen, mehrere Konzepte in einer Klasse auszudrücken, werden in Büchern als "markierte Klassen" bezeichnet.

Wenn Sie mehrere Konzepte ausdrücken möchten, teilen Sie die Klassen gehorsam auf. Verwenden wir insbesondere Vererbung / Subtypisierung, um sie in einer hierarchischen Struktur zu organisieren. Es ist natürlich.

Punkt 24 Wählen Sie eine statische Elementklasse gegenüber einer nicht statischen Elementklasse aus

Manchmal möchten Sie eine andere Klasse innerhalb einer Klasse deklarieren. In diesem Zusammenhang wird die erstere Klasse als "einschließende Klasse" und die letztere Klasse als "verschachtelte Klasse" bezeichnet.

Es gibt verschiedene Möglichkeiten, verschachtelte Klassen zu implementieren. Insbesondere gibt es die folgenden vier.

• statische Mitgliedsklasse
• Nicht statische Mitgliedsklasse
• Anonyme Klasse
• Lokale Klasse (eine Klasse, die in einer Methode mit einem Namen deklariert wurde)

Lassen Sie uns diese richtig verwenden. In Anbetracht des folgenden Ablaufs sollte kein Fehler vorliegen.

Untersuchungsschritt 0

Ist es möglich, dass die von Ihnen erstellte "verschachtelte Klasse" unabhängig von der einschließenden Klasse von anderen Klassen verwendet wird?

Wenn JA, sollte es überhaupt nicht als verschachtelte Klasse erstellt werden. Es sollte als gewöhnliche Klasse erstellt werden, unabhängig von der einschließenden Klasse.

Untersuchungsschritt 1

Wenn die "verschachtelte Klasse", die Sie erstellen möchten, alle folgenden ist, verwenden Sie ** anonyme Klasse **.

• Wird nur in bestimmten Methoden der einschließenden Klasse verwendet.
• Der Deklarationsteil der verschachtelten Klasse ist kurz. Wenn es zu lang ist, sind die Methoden der einschließenden Klasse schwer zu lesen.
• ** Nur an einem Ort ** Sofort.

Wenn eine anonyme Klasse in einer nicht statischen Methode der einschließenden Klasse deklariert wird, verweist die Instanz der anonymen Klasse automatisch auf die Instanz der einschließenden Klasse. In einigen Fällen führt dies zu einem Speicherverlust. Seien Sie sich der Gefahr bewusst, bevor Sie es verwenden.

Dies ist nicht der Fall, wenn es in einer nicht statischen Methode deklariert wird.

Untersuchungsschritt 2

Wenn die "verschachtelte Klasse", die Sie erstellen möchten, alle folgenden ist, verwenden Sie ** lokale Klasse **.

• Wird nur in bestimmten Methoden der einschließenden Klasse verwendet.
• Der Deklarationsteil der verschachtelten Klasse ist kurz.
• Instanziieren ** an mehreren Stellen innerhalb dieser Methode. Wenn es an mehreren Stellen verwendet wird, muss es mit einem Namen deklariert werden.

Untersuchungsschritt 3

Wenn die "verschachtelte Klasse", die Sie erstellen möchten, alle folgenden ist, verwenden Sie eine ** nicht statische Mitgliedsklasse **.

• Eine der folgenden Bedingungen gilt.
• Der Deklarationsteil der verschachtelten Klasse ist lang.
• Wird von mehreren Methoden der einschließenden Klasse verwendet.
• Der Zugriff auf eine Instanz der einschließenden Klasse ** ist **. Wenn eine nicht statische Mitgliedsklasse instanziiert wird, verweist sie automatisch auf eine Instanz der einschließenden Klasse von dieser Instanz. In einigen Fällen führt dies zu einem Speicherverlust. Seien Sie sich der Gefahr bewusst, bevor Sie es verwenden.

Untersuchungsschritt 4

Wenn die "verschachtelte Klasse", die Sie erstellen möchten, alle folgenden ist, verwenden Sie ** statische Elementklassen **.

• Eine der folgenden Bedingungen gilt.
• Der Deklarationsteil der verschachtelten Klasse ist lang.
• Wird von mehreren Methoden der einschließenden Klasse verwendet.
• Kein Zugriff auf eine Instanz der einschließenden Klasse **. Es besteht keine Gefahr wie bei nicht statischen Elementklassen. Wählen Sie diese Option daher so oft wie möglich.

Punkt 25 Beschränken Sie Quelldateien auf eine einzelne Klasse der obersten Ebene

Normalerweise würden Sie nicht mehrere Klassen der obersten Ebene in einer Quelldatei implementieren. In diesem Artikel wird erklärt, warum es sich um NG handelt, aber Sie müssen den Grund nicht kennen, da Sie dies in der Praxis überhaupt nicht tun. (Ende)

Kapitel 5 Generika

Punkt 26: Verwenden Sie den Prototyp nicht

Ein Prototyp ist ein Ausdruck, der keinen Typparameter enthält, z. B. "Liste" anstelle von "Liste ".

Es ist nicht mehr normal, dass Sie den Prototyp nicht verwenden sollten. Der Grund ist, dass Sie zur Laufzeit möglicherweise eine ClassCastException erhalten. Wenn Sie es mit Typparametern implementieren, können Sie solche Risiken in Form von Kompilierungsfehlern und Warnungen zur Kompilierungszeit feststellen. Verwenden wir nicht den Prototyp.

Es gibt jedoch Situationen, in denen Sie den Prototyp möglicherweise versehentlich verwenden. Insbesondere ist es wie folgt.

【NG】

//Tun Sie dies nicht nur, weil Sie die Typparameter von Set nicht kennen.
static int numElementsInCommon(Set s1, Set s2) {
    int result = 0;
    for (Object o1 : s1)
        if(s2.contains(o1))
            result++;
    return result;
}

Lassen Sie es uns wie folgt implementieren.

【OK】

//Dies führt zu einem Kompilierungsfehler, wenn versucht wird, Elemente zu s1 oder s2 hinzuzufügen.
//Es ist definitiv besser, als es zur Laufzeit zu bemerken. (Es kann jedoch null hinzugefügt werden.)
static int numElementsInCommon(Set<?> s1, Set<?> s2) {
    //Abkürzung
}

Punkt 27 Entfernen Sie die nicht inspizierte Warnung

Bei der Implementierung mit Generika können die Risiken, die zur Laufzeit zu einer ClassCastException führen, durch Kompilierungsfehler und Warnungen zur Kompilierungszeit erkannt werden.

Sie können die Warnungen kompilieren, wenn Sie sie in Ruhe lassen. Reagieren Sie jedoch in der Regel auf alle Warnungen und korrigieren Sie sie, damit sie nicht angezeigt werden. Fügen Sie "@SuppressWarning (" nicht markiert ")" hinzu, um die Warnung nur zu unterdrücken, wenn es wirklich kein Problem gibt. Übrigens ist "nicht markiert" eine Warnung, die bedeutet "Ich habe den Typ nicht überprüft, aber ist es in Ordnung?"

Wenn Sie die Warnung nicht unterdrücken, wenn es sich nicht wirklich um ein Problem handelt, können Sie die Warnung, die wirklich ein Problem darstellt, nicht bemerken. Lassen Sie uns dort auch keine Ecken abschneiden.

Punkt 28 Wählen Sie eine Liste aus einem Array aus

Sequenzen und Generika haben aufgrund ihres historischen Hintergrunds unterschiedliche Eigenschaften. Aus diesem Grund verursacht die kombinierte Verwendung Probleme. Implementieren Sie diese einheitlich in Generics, es sei denn, es gibt wesentliche Probleme mit der Einfachheit oder Leistung des Codes.

Welche Probleme treten bei kombinierter Anwendung auf?

Wenn Sie beide in Kombination implementieren, verstehen Sie die Bedeutung der vom Compiler ausgegebenen Fehler und Warnungen nicht und sind unnötig verwirrt. In einigen Fällen wird die Warnung ohne sorgfältige Überlegung unterdrückt, was zu einer ClassCastException führt oder die Wartungsmitglieder fragt: "Warum machen Sie hier" @ SuppressWarning "...?" Wird umarmt und verwirrt sein.

Zum Beispiel ...

• Ein Array mit Generika als Element, wie z. B. "List []", führt zu einem Kompilierungsfehler. Wenn Sie dies zulassen, können Sie eine ClassCastException erhalten. Sie könnten denken, dass es keine Rolle spielt, weil Sie das nicht tun, aber das ist nicht der Fall. Beispielsweise erstellt eine Argumentmethode mit variabler Länge ein Array, das Argumente mit variabler Länge enthält. Wenn Sie das Argument generisch machen, erhalten Sie eine Warnung, die schwer zu verstehen ist. Wenn Sie nicht verstehen, was hinter den Kulissen passiert, können Sie es nicht richtig lösen. new E [] ist auch nutzlos.

• Als Ergebnis der Ad-hoc-Implementierung ohne Verständnis der Bedeutung von Kompilierungsfehlern und -warnungen werden die folgenden NG-Klassen erstellt.

  public class Chooserr<T> {
      private final T[] choiceArray;
  
      public Chooser(Collection<T> choices) {
          //Auswahlmöglichkeiten können der Typ sein, der T enthält.
          //Oft zu Array()Ist T.[]Es sollte keine Garantie dafür geben, dass es zurückkommt.
          //Möglicherweise erhalten Sie zur Laufzeit eine ClassCastException.
          //Ich verstehe die Bedeutung nicht@Es ist NG, Warnungen zu unterdrücken.
          @SuppressWarning("unchecked")
          choiceArray = (T[]) choices.toArray();
      }
  }
  

Warum passiert das?

Dies liegt daran, dass es die folgenden Unterschiede zwischen den beiden gibt. (Obwohl es im Buch erklärt wird, erklärt es nicht, warum diese Unterschiede zu dem oben genannten Problem führen ... Ich werde später einen Kommentar hinzufügen, wenn ich Zeit habe.)

• Kovariante wird als Kovariante übersetzt und Invariante wird als unveränderlich übersetzt, aber diese japanischen Übersetzungen führen nur zu Verwirrung. Du solltest dich besser nicht erinnern.

Punkt 29 Verwenden Sie einen generischen Typ

Wenn Sie Ihre eigene Klasse erstellen, sollten Sie sie so allgemein wie möglich gestalten. Auf diese Weise haben Benutzer die folgenden Vorteile:

• Sie können das Risiko einer ClassCastException zur Laufzeit beseitigen.
• Benutzer müssen den Rückgabewert nicht einzeln umwandeln.

In einigen Fällen ist es möglicherweise besser, Arrays in Ihrer eigenen Klasse zu verwenden. Zum Beispiel, wenn Sie einen generischen Basistyp wie ArrayList erstellen möchten oder wenn Sie einen Leistungsgrund haben.

In diesen Fällen müssen Sie "@SuppressWanings (" nicht markiert ")" innerhalb der Klasse ausführen, um Warnungen zur Kompilierungszeit zu unterdrücken. Natürlich sollten wir sorgfältig überlegen, ob es wirklich angemessen ist, dies zu unterdrücken.

Punkt 30 Verwenden Sie eine generische Methode

Wenn Sie Ihre eigene Methode erstellen, sollten Sie sie so allgemein wie möglich gestalten. Auf diese Weise erhält der Benutzer die gleichen Vorteile wie unter Punkt 29.

Zunächst werde ich den Fall der Definition einer normalen generischen Methode erläutern.

[NG] Nicht generische Methode

//Wenn sich die zu haltenden Objekttypen zwischen s1 und s2 unterscheiden, wird zur Laufzeit eine ClassCastException ausgeführt.
public static Set union(Set s1, Set s2) {
    Set reslut = new HashSet(s1);
    result.addAll(s2);
    return result;
}

[OK] Generische Methode

//Der in der Methode verwendete Typparameter (Liste der) muss zwischen dem Qualifizierer und dem Rückgabetyp deklariert werden.
//In diesem Beispiel ist es unmittelbar nach statisch<E>Das ist.
public static <E> Set<E> union(Set<E> s1, Set<E> s2) {
    Set<E> reslut = new HashSet<>(s1);
    result.addAll(s2);
    return result;
}

Als nächstes wird eine erweiterte generische Methode implementiert. Ich werde die folgenden zwei Techniken vorstellen.

• Generische Singleton Factory
• Rekursive Grenze

Technik Nr. 1: Generische Singleton-Fabrik

Angenommen, Sie benötigen eine API, die die Aufgabe hat, ein Objekt zurückzugeben, das mit dem von Ihnen angegebenen Typ funktioniert. Wenn das zu erstellende Objekt keinen Status hat, ist es sinnlos, das Objekt jedes Mal zu erstellen, da der vom Benutzer angegebene Typ unterschiedlich ist.

Die generische Singleton-Factory ist eine Technik, mit der das Objekt mit einem Singleton versehen werden kann (dh um die Kosten für die Erstellung einer Instanz und den verwendeten Speicher zu reduzieren), während der vom Benutzer angegebene Typ ausgeführt wird.

Das Buch gibt ein Beispiel dafür mit der konstanten Funktion. Übrigens ist eine Gleichheitsfunktion eine Funktion, die Parameter so zurückgibt, wie sie sind. Wofür ist es nützlich? Sie können denken, dass es als eine der Aktivierungsfunktionen im Bereich des maschinellen Lernens erscheint. Ich muss etwas in der API als Aktivierungsfunktion angeben, aber ich möchte nichts tun, daher gibt es eine Verwendung wie die Angabe einer Funktion, die praktisch nichts tut.

//Punkt dieser Technik ①
private static UnaryOperator<Object> IDENTITY_FN = (t) -> t;

//Punkt dieser Technik ②
@SuppressWarnings("unchecked")
public static <T> UnaryOperator<T> identityFunction() {
    return (UnaryOperator<T>) IDENTITY_FN;
}

** Punkte dieser Technik ① **

Da die Generika im Radiergummi implementiert sind, ist es in Ordnung, nur eine Instanz mit dem Namen IDENTITY_FN zurückzugeben, unabhängig davon, welcher Typ vom Benutzer angegeben wird.

Wenn andererseits die Generika verkörpert sind, dh wenn sich IDENTITY_FN auch zur Laufzeit an den vom Benutzer angegebenen Typparameter erinnert, kann eine Instanz namens IDENTITY_FN nicht damit umgehen.

Wenn ein Benutzer beispielsweise identityFunction () mit einem String als Typparameter aufruft, muss IDENTITY_FN "UnaryOperator " sein (eine Welt, in der Generika enthalten sind). In diesem Fall muss die Long-Version von IDENTITY_FN vorbereitet werden, um der Person zu entsprechen, die Long als Typparameter angeben möchte. Sie benötigen außerdem eine Long-Version der identityFunction () -Methode, die dieses Objekt zurückgibt.

** Punkt dieser Technik ② **

Wenn ich versuche, eine generische Singleton-Factory zu implementieren, habe ich sie ohne Inspektion gegossen. Ist das in Ordnung? Wird gewarnt. Aber in vielen Fällen ist es okay. Erkennen Sie den Grund und unterdrücken Sie die Warnung.

Was bedeutet die nicht inspizierte Besetzungswarnung in diesem Beispiel?

"UnaryOperator " soll mit einem "bestimmten Typ" namens "Objekt" arbeiten. Objekt ist der allgemeinste Typ, aber da es als ein in T enthaltener Typ positioniert ist, der alle Typen darstellt, wird es als "spezifischer Typ" ausgedrückt.

Andererseits bedeutet das T in "UnaryOperator " alle Typen, aber wenn der Benutzer es verwendet, ist es auf einen Typ festgelegt. Sie wird durch den vom Benutzer angegebenen Typ bestimmt.

Wenn UnaryOperator , der mit einem bestimmten Typ arbeiten soll, als UnaryOperator des vom Benutzer angegebenen Typs behandelt wird, wird "vom Benutzer angegebener Typ" in "" geändert. Möglicherweise können Sie nicht in einen bestimmten Typ umwandeln, und Sie erhalten möglicherweise eine ClassCastException. Von einem unbekannten Compiler kann die Möglichkeit nicht ausgeschlossen werden.

Diese Meldungen sind in der Warnung enthalten.

In diesem Fall wird das vom Benutzer übergebene Argument jedoch einfach unverändert zurückgegeben. Um genau zu sein, wird es zur Laufzeit intern vom "benutzerdefinierten Typ" in Object umgewandelt. Da es jedoch in etwas umgewandelt wird, das an der Spitze der Klassenhierarchie namens Object steht, kann keine ClassCastException auftreten. Aus diesem Grund ist es kein Problem, die Warnung mit dem Gefühl zu unterdrücken, dass "Compiler, diesmal ist es in Ordnung".

** Hinweis: Warum verursacht diese Besetzung keinen Kompilierungsfehler? ** ** **

Im Teil "return (UnaryOperator ) IDENTITY_FN;" wird eine nicht überprüfte Besetzungswarnung angezeigt. Warum kann "UnaryOperator " überhaupt in "UnaryOperator " umgewandelt werden? Warum erhalten Sie keinen Kompilierungsfehler?

Die Generika sind unveränderlich, so dass "List