Aktualisierungen von Effective Java Third Edition 2nd Edition Persönliche Notizen

Die von mir bestellte * Effective Java Third Edition * ist endlich eingetroffen, daher habe ich die Änderungen gegenüber der zweiten Edition zusammengefasst. Ich habe die persönlichen Notizen und die Teile übersprungen, die sich nicht von der zweiten Ausgabe unterscheiden. Bitte verzeihen Sie mir etwaige Auslassungen. Da sich die zweite Ausgabe auf die japanische Version bezieht, kann es zu Inkonsistenzen in Bezug auf den übersetzten Text kommen. Ich wäre Ihnen dankbar, wenn Sie auf Fehler hinweisen könnten.

Gebrauchsanweisung

Zitat aus Effective Java Third Edition oder dessen Übersetzung

• Zusammenfassung des Inhalts

Klartext - Individueller Eindruck

Item 2

Der Builder wurde mit rekursiven Parametern hinzugefügt. Sie können Unterklassen fließend entwerfen, indem Sie den von der übergeordneten abstrakten Klasse "Pizza" zurückgegebenen Builder auf "Builder <T erweitert Builder >" und den von der Methode "addTopping ()" auf "T" zurückgegebenen Typ setzen. ..

Punkt 5: Verwenden Sie die Abhängigkeitsinjektion anstelle von Hardcode-Ressourcen

** Statische Dienstprogrammklassen und Singletons sind nicht für Klassen geeignet, deren Verhalten durch Ressourcen parametrisiert werden kann **

• Übergeben Sie "Supplier " anstelle von "Pass Factory".

Item 6

Das Beispiel für das Erstellen unnötiger Objekte wurde von "Kalender" in "String.matches ()" geändert (das Problem besteht darin, dass jedes Mal "Muster" erstellt wird).

Punkt 8: Vermeiden Sie Finalisierer und Reiniger

Über den in Java 9 hinzugefügten Reiniger wurde gesprochen.

** Reiniger sind nicht so gefährlich wie Finalisierer, aber sie sind immer noch unvorhersehbar, langsam und im Allgemeinen unnötig **

• Finalizer-Angriff - Verwenden Sie den Finalizer, um das schädliche Objekt auf dem Heap zu belassen und die Methode aufzurufen (die Beschreibung selbst war ebenfalls in der 2. Ausgabe enthalten, wird jedoch stärker betont).

• Sollte stattdessen "AutoCloseable" implementieren

Punkt 9: Verwenden Sie Try-with-Resources, anstatt Try-finally

• try-finally ist leicht Fehler zu machen (Block selbst Fehler, JDK Implementierungsfehler)

Item 10

• Es ist schwierig, "equals ()" zu implementieren. Verwenden Sie AutoValue oder lassen Sie es von der IDE generieren

Persönlich mag ich AutoValue nicht sehr, deshalb benutze ich Lombok oder schreibe es in Kotlin.

IDEs do not make careless mistakes, and humans do IDEs machen keine versehentlichen Fehler, aber Menschen

Item 11

Das Codebeispiel wurde geändert, um "Type.hashCode ()" (z. B. "Short.hashCode ()") zum Generieren des Hash-Codes zu verwenden. In Bezug auf die Dokumentation zum Generieren von hashCode ist der Ausdruck von "nicht tun" auf "nicht tun" stärker geworden (die Dokumentation macht es unmöglich, in Zukunft Änderungen vorzunehmen).

Item 12

• In statischen Dienstprogrammklassen oder Enumeratoren benötigen Sie kein toString ()

Item 13

• Unveränderliche Klassen dürfen nicht "klonbar" bereitstellen (können ohne Kopieren geteilt werden)

Item 14

• Verwenden Sie "Type.compare ()"
• Verwenden Sie Comparator.comparing ... ()
• Verwenden Sie keine diff-basierten Komparatoren (solche, die Werte zwischen Objekten subtrahieren) (Überlauf)

Item 15

• Es ist noch nicht bekannt, ob Java 9-Module weit verbreitet sein werden.
• Das Modul ist "beratend". Sie müssen es nicht erzwingen.

Item 19

• Verwenden Sie "@ implSpec"

Item 20

• Abstrakte Klassen sind immer noch nützlich, da die Standardmethoden nützlich, aber begrenzt sind.

Punkt 21: Entwerfen Sie die Schnittstelle für die Zukunft

** Es ist nicht immer möglich, eine Standardmethode zu schreiben, ohne alle möglichen Implementierungen zu ändern ** ** Es ist nach wie vor von größter Wichtigkeit, beim Entwerfen einer Schnittstelle große Sorgfalt walten zu lassen **

• z. B. Apache Commons synchronizedCollection Die Standardmethode wird nicht synchronisiert (bis sie überschrieben wird)!
• Sie können eine Schnittstelle nicht entwerfen, nur weil sie eine Standardmethode hat

Alter Artikel 21

Gelöscht, zusammengeführt in Punkt 42

Item 24

• Mit dem Hinzufügen von Lambdas werden Funktions- und Prozessobjekte nicht mehr benötigt

Punkt 25: Schreiben Sie nur eine Klasse der obersten Ebene in die Quelldatei

• Wenn Sie versehentlich eine Quelle mit demselben Namen erstellen, können Sie sie möglicherweise nicht kompilieren.

Sie können mehrere öffentliche Klassen in einer Sprache wie Kotlin schreiben, aber ich denke, es ist besser, sie aus Gründen der Lesbarkeit so weit wie möglich voneinander zu trennen.

Punkt 26: Verwenden Sie keinen Prototyp

"Mit neuem Code" ist weg (nicht zwangsweise überarbeitet)

Item 27:

Beschreibung des Diamantoperators

Item 30

Mit dem Hinzufügen des Diamantoperators ist die Beschreibung der Dienstprogrammmethode "newHashMap" zum Weglassen von Typparametern beim Erstellen einer neuen Sammlung verschwunden.

generic singleton pattern

private static UnaryOperator<Object> IDENTITY_FN = (t) -> t;
@SuppressWarnings("unchecked")
public static <T> UnaryOperator<T> identityFunction() {
    return (UnaryOperator<T>) IDENTITY_FN;
}

Ich glaube nicht, dass ich viele Möglichkeiten habe, es in tatsächlichen Schlachten einzusetzen.

Punkt 32: Kombinieren Sie generische Typen und Argumente variabler Länge sorgfältig

• Verwenden Sie immer "@ SafeVarargs" und stoppen Sie, wenn Sie unsicher sind

Item 34

Von String in Enum konvertieren

private static final Map<String, Operation> stringToEnum = Stream.of(values()).collect(toMap(Object::toString, e -> e));
public static Optional<Operation> fromString(String symbol) {
    return Optional.ofNufllable(stringToEnum.get(symbol));
}

Ich persönlich möchte eine Ausnahme auslösen (siehe Punkt 55).

Der "Payroll Day" wurde subtil überarbeitet.

Item 37

Warum haben Sie Herb in Plant und Type in Lifecycle geändert?

Item 39

JUnit -> JUnit 3 JUnit 4 basiert auf Anmerkungen, daher folge ich genau den Ratschlägen in diesem Abschnitt.

Punkt 42: Verwenden Sie Lambda anstelle einer anonymen Klasse

Lambda-Parametertypen werden nur verwendet, wenn das Programm dadurch sauberer wird. Lambda fehlen Name und Dokumentation. Verwenden Sie keine Lambdas, wenn der Vorgang nicht selbsterklärend oder größer als einige Zeilen ist.

• Wenn Sie einen Verweis auf sich selbst benötigen, benötigen Sie eine anonyme Klasse
• Lambda darf nicht serialisiert werden

Punkt 43: Verwenden Sie Methodenreferenzen anstelle von Lambda

• Wenn es prägnanter ist, Lambda zu verwenden, tun Sie dies (z. B. Function :: identity vs x-> x)

Punkt 44: Verwenden Sie die Standardfunktionsschnittstelle

Das Muster "Vorlagenmethode", bei dem Unterklassen "primitive Methoden" überschreiben, um das Verhalten von Oberklassen anzupassen, ist viel weniger attraktiv. Eine moderne Alternative besteht darin, eine statische Factory oder einen statischen Konstruktor bereitzustellen, der Funktionsobjekte akzeptiert, die dasselbe tun.

• Verwenden Sie die Standardschnittstelle, anstatt eine eigene Funktionsschnittstelle zu erstellen

• Bei der Definition Ihrer eigenen Funktionsschnittstelle

• Weit verbreitet und von beschreibenden Namen profitierend

• Wenn Sie einen stark verwandten Vertrag haben

• Wenn Sie von Ihrer eigenen Standardmethode profitieren

• Verwenden Sie "@ FunctionalInterface"

Erstellen Sie keine unterschiedlichen überladenen Methoden mit unterschiedlichen Funktionsschnittstellen an derselben Position wie Argumente, wenn diese für den Client nicht eindeutig sein können.

• z. B. "ExecutorService.submit ()" ist verwirrend, da "Runnable" und "Callable " erforderlich sind.

Punkt 45: Verwenden Sie Streams mit Vorsicht

just because you can doesn't mean you should

** Übermäßiger Gebrauch von Streams macht das Programm schwer lesbar und wartbar **

Ich habe Ohrenschmerzen

** Die Verwendung von Hilfsmethoden in Code, der Stream-Pipelines verwendet, ist noch wichtiger als in Code, der Iteratoren verwendet. ** ** **

• Verwenden Sie Stream nicht für "char"

Der Methodenname (primes) ist eine Pluralnomenklatur, die die Elemente des Streams beschreibt. Diese Namenskonvention verbessert die Lesbarkeit der Stream-Pipeline und wird für alle Methoden, die einen Stream zurückgeben, dringend empfohlen.

Punkt 46: Verwenden Sie eine Funktion ohne Nebenwirkungen im Stream

• Um Stream verwenden zu können, müssen Sie sich sowohl an das Paradigma (der funktionalen Programmierung) als auch an die API anpassen.

Die Anweisung "forEach" sollte nur verwendet werden, um die Verarbeitungsergebnisse eines Streams zu melden, und keine Verarbeitung.

Es ist leicht, "forEach (e-> list.add (e))" zu sagen.

Punkt 47: Verwenden Sie die Sammlung anstelle des Streams für den Rückgabewert

Wenn Sie eine öffentliche API schreiben, die eine Sequenz zurückgibt, sollten Sie diese nicht nur für diejenigen schreiben, die Stream-Pipelines schreiben möchten, sondern auch für diejenigen, die für jede Anweisung schreiben möchten.

** Speichern Sie keine großen Sequenzen im Speicher, nur um sie als Sammlung zurückzugeben. ** ** **

Erwägen Sie die Implementierung einer Sammlung für einen bestimmten Zweck.

Punkt 48: Streams sorgfältig parallelisieren

** Wenn die Quelle "Stream.iterate" ist oder das Grenzwert "Zwischenoperation" verwendet wird, verbessert die Parallelisierung der Pipeline die Leistung nicht. ** ** **

• Parallelisieren Sie Streams nicht wahllos

** Das Parallelisieren von Streams von "ArrayList" -, "HashMap" -, "HashSet" -, "ConcurrentHashMap" -Instanzen, Arrays, "Int" -Bereich und "Long" -Bereich ist der größte Leistungsgewinn. Machen wir das. ** ** **

• Das Parallelisieren von Streams verlangsamt nicht nur die Leistung, sondern kann auch zu falschen Ergebnissen und unvorhersehbarem Verhalten führen.

• Unterschied zwischen "forEach" und "forEachOrdered"

• Grobe Anleitung: Die Leistung kann sich verbessern, wenn "Stream-Elemente x Codezeilen> 100.000" überschritten wird Quelle im Buch: Wann parallele Streams verwendet werden sollen

Es ist wichtig zu beachten, dass die Stream-Parallelisierung eine Leistungsoptimierung darstellt. Wie bei jeder Optimierung müssen Sie die Leistung vor und nach der Änderung messen, um sicherzustellen, dass Sie dies tun müssen.

Item 49

• Verwenden Sie Objects.requireNonNull

Item 50

** Datum ist veraltet und sollte nicht mehr in neuem Code verwendet werden **

Punkt 55: Vorsichtig optional zurücksenden

** Containertypen und Optionen wie Karten, Streams und Arrays dürfen nicht optional verpackt werden. Deklarieren Sie eine Methode zur Rückgabe von "Optional ", wenn möglicherweise keine Ergebnisse * und * zurückgegeben werden und der Client etwas Besonderes tun muss. ** ** **

• Verwenden Sie "OptionalInt", "OptionalLong", "OptionalDouble". Wenn es sich um "Optional " handelt, tritt ein automatisches Boxen auf und die Leistung verschlechtert sich.

• Verwenden Sie keine Optionen für Sammlungs- oder Array-Schlüssel, -Werte oder -Elemente

• Das Speichern von Optionen in Feldern ist oft ein "Geruch" -Code, kann aber auch gerechtfertigt sein (z. B. wenn Sie viele optionale Felder haben und nur das optionale vom Getter zurückgeben müssen).

Item 56

• Verwenden Sie "@ implSpec"
• Beachten Sie den Punkt (gilt als das Ende des Satzes)

Item 59

• Verwenden Sie "ThreadLocalRandom" anstelle von "Random"
• Guave ist praktisch

Altes Element 73: Vermeiden Sie Thread-Gruppen

Löschen

Item 75

• Ein Konstruktor mit "int index" als Argument zu "IndexOutOfBoundsException" in Java 9 wurde hinzugefügt.

Punkt 80: Wählen Sie Executor, Task und Stream aus dem Thread aus

Der Stream wurde als Kandidat hinzugefügt.

Punkt 85: Verwenden Sie Alternativen anstelle der Java-Serialisierung

Die Gefahr der Serialisierung wird stark betont.

• Fallstudie: [San Francisco Municipal Railway](https://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%B3%E3%83%95%E3%83%A9%E3%83 % B3% E3% 82% B7% E3% 82% B9% E3% 82% B3% E5% B8% 82% E5% 96% B6% E9% 89% 84% E9% 81% 93) über zwei Tage Stop
• Sicherheitslücken in Apache Commons Collections

** Der beste Weg, um Serialisierungsschwachstellen zu vermeiden, besteht darin, nichts zu deserialisieren ** ** Es gibt keinen Grund, die Java-Serialisierung auf neu geschriebenen Systemen zu verwenden **

• Alternative: JSON, Protobuf

Das nächstbeste ist, ** niemals nicht vertrauenswürdige Daten zu deserialisieren **

• Wenn Sie wirklich einen Serializer benötigen, verwenden Sie "java.io.ObjectInputFilter"

Zusammenfassend ist die Serialisierung gefährlich und sollte nicht verwendet werden.

Impressionen

• In Bezug auf neue Teile gibt es nur gesunden Menschenverstand und nichts Neues
• Ist es jedoch sinnvoll, den gesunden Menschenverstand neu zu lernen?
• Wie erwartet warnt es vor der blinden Verwendung von Streams
• Es ist sehr gut, dass die Gefahr der Serialisierung hervorgehoben wird
• Die Bekanntheit von Google nimmt zu (Herr Brock ist ein ehemaliger Google-Mitarbeiter).
• Es wurde insgesamt aufgefrischt. Wenn Sie es noch nicht haben, sollten Sie es kaufen, sobald eine japanische Übersetzung verfügbar ist. Ich frage mich, ob diejenigen, die es haben, ein neues kaufen müssen.

Bonus-Mr. Brocks PC