Effektive Java 3rd Edition Kapitel 2 Objekterstellung und Verschwindenlassen

[Effective Java 3rd Edition](https://www.amazon.co.jp/Effective-Java-%E7%AC%AC3%E7%89%88-%E3%], ein Muss für fortgeschrittene Java-Benutzer und höher. 82% B8% E3% 83% A7% E3% 82% B7% E3% 83% A5% E3% 82% A2% E3% 83% BB% E3% 83% 96% E3% 83% AD% E3% 83% 83% E3% 82% AF-ebook / dp / B07RHX1K53) hat eine Kindle-Version, daher werde ich sie zusammenfassen. "Kapitel 1 Einführung" ist hauptsächlich eine Erklärung der Begriffe, daher werde ich sie überspringen.

Zurück: Keine Weiter: Effektive Java 3rd Edition, Kapitel 3, allen Objekten gemeinsame Methoden

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

• Die statische Factory-Methode ist so etwas wie "Boolean.valueOf (boolean b)".

[Good]Beispiel für eine statische Factory-Methode

public static Boolean valueOf(boolean b) {
  return b ? Boolean.True : Boolean.False
}

--Vorteile der statischen Fabrikmethode

• Im Gegensatz zu Konstruktoren hat es einen Namen.
• Da der Konstruktor keinen Namen hat, ist es schwierig, die Funktion anhand des Parameters zu beurteilen.
• Im Gegensatz zu Konstruktoren müssen Sie nicht für jeden Aufruf ein neues Objekt erstellen.
• Vermeiden Sie die Erstellung unnötiger doppelter Objekte.
• Im Gegensatz zu Konstruktoren kann es Objekte eines beliebigen Subtyps des Rückgabetyps der Methode zurückgeben.
• Die Klasse des zurückgegebenen Objekts wird für jeden Aufruf abhängig vom Wert des Eingabeparameters geändert.
• Die Klasse des zurückgegebenen Objekts muss zum Zeitpunkt des Schreibens der Klasse mit der statischen Factory-Methode nicht vorhanden sein. --Statische Einschränkungen der Factory-Methode --Kann keine Unterklassen von Klassen erstellen, die keine öffentlichen oder geschützten Konstruktoren haben
• Beispielsweise können Sie keine Unterklasse einer der Dienstprogrammimplementierungsklassen im Auflistungsframework erstellen.
• Sie sollten Komposition verwenden, nicht Vererbung.
• Für den Programmierer ist es schwierig, die statische Factory-Methode zu finden.
• Konventionelle Namenskonvention für Factory-Methoden
  • from
  • of
  • valueOf
  • instance or getInstance
  • create or newInstance
  • getType
  • newType
  • type

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

[Good]Beispiel für eine Builder-Klasse

public class NutritionFacts {
    private final int savingSize;
    private final int savings;
    private final int calories;
    private final int fat;
    private final int sodium;
    private final int carbohydrate;

    public static class Builder {
        //Verpflichtend
        private final int savingSize;
        private final int savings;

        //Optionaler Standardwert
        private int calories = 0;
        private int fat = 0;
        private int sodium = 0;
        private int carbohydrate = 0;

        public Builder(int savingSize, int savings) {
            this.savingSize = savingSize;
            this.savings = savings;
        }

        public Builder calories(int val) {
            calories = val;
            return this;
        }

        public Builder fat(int val) {
            fat = val;
            return this;
        }

        public Builder sodium(int val) {
            sodium = val;
            return this;
        }

        public Builder carbohydrate(int val) {
            carbohydrate = val;
            return this;
        }

        public NutritionFacts build() {
            return new NutritionFacts(this);
        }

    }

    private NutritionFacts(Builder builder) {
        savingSize = builder.savingSize;
        savings = builder.savings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }
}

lombok @ Builder Verwendungsbeispiel

Beispiel mit Lombok

import lombok.Builder;
import lombok.NonNull;

@Builder
public class LombokNutritionFacts {

    //Verpflichtend
    @NonNull
    private final Integer savingSize;
    @NonNull
    private final Integer savings;

    //Festlegen des Standardwerts
    @Builder.Default
    private final Integer calories = 0;
    @Builder.Default
    private final Integer fat = 0;
    @Builder.Default
    private final Integer sodium = 0;
    @Builder.Default
    private final Integer carbohydrate = 0;
}

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

[Good]Singleton-Klasse mit Aufzählungstyp

//Singleton-Klasse mit Aufzählungstyp
public enum Elvis {
    INSTANCE;

    public void leaveTheBilding() {
        System.out.println("Hello Elvis!");
    }
}

//Beispiel aufrufen
public class Main {
    public static void main(String[] args){
        Elvis elvis = Elvis.INSTANCE;
        elvis.leaveTheBilding();
    }
}

Punkt 4 Unmöglichkeit der Instanziierung mit privatem Konstruktor erzwingen

[Good]

//Dienstprogrammklassen, die nicht instanziiert werden können
public class UtilityClass {
    //Erstellen Sie einen privaten Konstruktor, damit er nicht instanziiert werden kann
    private UtilityClass() {
        throw new AssertionError();  //Werfen, wenn in der Klasse gerufen
    }
    //Unten weggelassen
}

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

[Bad]

//Unsachgemäße Verwendung statischer Dienstprogramme. Es fehlt Flexibilität und kann nicht getestet werden.
public class SpellCheckerStatic {
    private static final Lexicon dictionary = new MyDictionary();

    private SpellCheckerStatic() {
    }
    public static boolean isValid(String word) {
        //Kürzung
    }
    public static List<String> suggestions(String type) {
        //Kürzung
    }
}

[Good]

//Die Abhängigkeitsinjektion ist flexibel und testbar
public class SpellChecker {
    private final Lexicon dictionary;

    public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }
    public boolean isValid(String word) {
        //Kürzung
    }
    public List<String> suggestions(String type) {
        //Kürzung
    }
}

Punkt 6 Vermeiden Sie unnötige Objekte

//Dadurch entstehen unnötige Objekte
String s = new String("bikini");
//Sollte das tun
String s = "bikini";

• Sie sollten statische Factory-Methoden anstelle von Konstruktoren verwenden. --Wählen Sie einen Basisdatentyp gegenüber einem Boxed-Basisdatentyp und achten Sie auf unbeabsichtigtes automatisches Boxen.

public class RomanNumerals {
    private static final Pattern ROMAN = Pattern.compile(
            "^(?=.)M*(C[MD]|D?C{0,3})" +
                    "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");

    //[Gutes Beispiel] Verbesserte Version, die Objekte wiederverwendet
    static boolean isRomanNumerial(String s) {
        return ROMAN.matcher(s).matches();
    }

    //[Kein gutes Beispiel] Bei wiederholter Verwendung ist die Leistung schlecht
    static boolean isRomanNumerialBad(String s) {
        return s.matches("^(?=.)M*(C[MD]|D?C{0,3})" +
                "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
    }
}

Punkt 7 Entfernen Sie Verweise auf veraltete Objekte

• Setzen Sie null für Referenzen, die nicht mehr verwendet werden.
• Das Setzen eines Objektverweises auf null sollte eher eine Ausnahme als normal sein.
• Der beste Weg, veraltete Referenzen zu entfernen, besteht darin, die Variablen, in denen sie enthalten sind, aus dem Gültigkeitsbereich zu entfernen.

public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;
    public Stack() {
        this.elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }
    public void push(Object e) {
        ensureCapacity();
        elements[size++] = e;
    }
    public Object pop() {
        if (size == 0)
            throw new EmptyStackException();
        Object result = elements[--size];
        elements[size] = null;  //■ Veraltete Verweise entfernen ■
        return result;
    }
    //Wenn Sie es größer machen müssen, verdoppeln Sie es. Sichern Sie mindestens eine Kapazität.
    private void ensureCapacity() {
        if (elements.length == size) {
            elements = Arrays.copyOf(elements, 2 * size + 1);
        }
    }
}

Punkt 8 Vermeiden Sie Finalisierer und Reiniger

• Finalisierer sind unvorhersehbar, normalerweise gefährlich und im Allgemeinen unnötig.
• Die Finalizer-Alternative von Java 9 ist sauberer, weniger gefährlich als der Finalizer, aber immer noch unvorhersehbar, langsam und wird im Allgemeinen nicht benötigt.
• Implementieren Sie anstelle eines Finalisierers oder Reinigers "AutoClosable" und fordern Sie den Aufruf der Methode close an, wenn sie nicht mehr benötigt wird. Verwenden Sie normalerweise try-with-resource zum Schließen.

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

wie der Name schon sagt.