Warum machen private static final Listen/Sets/Maps unveränderbar?

Gerade lese ich einige code, geschrieben von einem erfahrenen Programmierer, und ich kam auf Folgendes:

public class ConsoleFormatter extends Formatter {
    private static final Map<Level, String> PREFIXES;

    static {
        Map<Level, String> prefixes = new HashMap<Level, String>();
        prefixes.put(Level.CONFIG,  "[config]");
        prefixes.put(Level.FINE,    "[debug]");
        prefixes.put(Level.FINER,   "[debug]");
        prefixes.put(Level.FINEST,  "[trace]");
        prefixes.put(Level.INFO,    "[info]");
        prefixes.put(Level.SEVERE,  "[error]");
        prefixes.put(Level.WARNING, "[warning]");

        PREFIXES = Collections.unmodifiableMap(prefixes);
    }

    //...

}

Wie Sie sehen können, dies ist eine Klasse verwendet, für die Formatierung der log-Ausgabe. Was meine Aufmerksamkeit erregte, war jedoch der code in der statischen Initialisierung block: PREFIXES = Collections.unmodifiableMap(prefixes);.

Warum war PREFIXES machte eine unveränderliche Karte? Es ist eine private Konstante, es gibt also kein Risiko, dass das ändern der Daten außerhalb der Klasse. War es zu den Konstanten der Unveränderlichkeit ein Gefühl der Vollständigkeit?

Persönlich, ich würde habe direkt initialisiert PREFIXES als HashMap und dann put Schlüssel–Wert-Paare direkt, ohne einen dummy-Platzhalter-Karte oder das Feld eine unveränderliche Karte. Bin ich hier etwas fehlt?

  • Es könnte auch gedacht werden, um zu verhindern, dass die gleichzeitige Initialisierung Probleme beim instanziieren der Klasse, weil der einzelne Schritt Zuordnung zu PRÄFIXEN der gesamten Daten.
InformationsquelleAutor Konstantin | 2012-12-10
  1. 9

    Durch die Liste unmodifiable der Autor dokumentiert seine Annahme, dass die Werte nie ändern wird. Wer kann Bearbeiten, dass die Klasse später nicht nur sehen, dass die Annahme, wird aber auch daran erinnert werden, falls es jemals kaputt.

    Diese macht nur Sinn, wenn man die längerfristige Sicht. Es reduziert das Risiko, dass neue Probleme entstehen durch die Wartung. Ich mag zu tun diese Art der Programmierung, denn ich Neige dazu, zu brechen Zeug auch in meinen eigenen Klassen. Eines Tages könnten Sie gehen für ein "quick fix", und Sie vergessen, über eine Annahme, die gemacht wurde, ursprünglich-und ist relevant für Korrektheit. Je mehr Sie können, sperren Sie den code unten, desto besser.

    • "Eines Tages könnten Sie gehen für ein "quick fix", und Sie vergessen, über eine Annahme, die gemacht wurde, ursprünglich-und ist relevant für Korrektheit." Oh boy, ich weiß genau was du meinst.
    InformationsquelleAutor Peter Becker
  2. 9

    Wenn Sie versehentlich return PREFIXES von einer Methode, plötzlich andere Codes gibt, kann es ändern. Machen Konstanten wirklich unveränderlich verteidigt gegen Ihre eigene Dummheit, wenn Sie ändern Sie den code in der Zukunft um 3 Uhr morgens.

    • genau... Sonst final wäre unvollständig, für die Map<Level, String> PREFIXES Karte.
    InformationsquelleAutor Louis Wasserman
  3. 3

    Es ist überraschend einfach, einen private map, collection oder ein array, die änderbar ist von außerhalb der Klasse. Sie hatte mark es final, warum dann nicht auch Zauber aus, der es sein soll unveränderlich sein, wie gut?

    • Ich sehe Ihren Punkt, aber es gibt keinen Getter für den genannten Bereich. Werden Sie sagen, dass es eine gute übung, um Sie unveränderlich sowieso, nur für den Fall?
    • Muss nicht sein, ein getter. Mein Lieblings-Beispiel ist in Michael Feder ' s Arbeiten Mit Legacy Code. In Kapitel 13 geht er in die unglaublich langweilige Details darüber, wie Sie Objekte können Auslaufen. Und in Kapitel 14, er stellt eine private static array. Wenn er das macht, dann bin ich nicht erwartet, eine normale Programmierer, um es richtig zu machen - es sei denn, Sie sehr explizit ausblenden, das veränderliche Objekt hinter eine unveränderliche wrapper.
    InformationsquelleAutor Tom Hawtin - tackline
  4. 3

    Angenommen, Ihr Freund verlässt seinen job und ein weniger erfahrener Programmierer übernimmt. Der weniger erfahrene Programmierer versucht, ändern Sie den Inhalt der PRÄFIXE irgendwo in einer anderen Methode in der gleichen Klasse. Es ist unveränderbar, es wird nicht funktionieren. Es ist der richtige Weg, zu sagen: "dies ist ein ständiger, nicht immer verändern."

    InformationsquelleAutor Diego Basch
  5. 1

    Die Map-Schnittstelle nicht kommunizieren, dass Sie wollen, dass etwas unveränderlich oder unveränderbar.

    Folgende Ansätze werden in Eclipse-Sammlungen.

    private static final ImmutableMap<Level, String> PREFIXES = UnifiedMap.<Level, String>newMap()
    .withKeyValue(Level.CONFIG, "[config]")
    .withKeyValue(Level.FINE, "[debug]")
    .withKeyValue(Level.FINER, "[debug]")
    .withKeyValue(Level.FINEST, "[trace]")
    .withKeyValue(Level.INFO, "[info]")
    .withKeyValue(Level.SEVERE, "[error]")
    .withKeyValue(Level.WARNING, "[warning]")
    .toImmutable();

    Diesem wird eine Karte erstellen, die vertraglich unveränderlich, weil ImmutableMap hat keine verändernde Methoden in der API.

    Wenn Sie es vorziehen, um zu halten die Map-Schnittstelle wird dieser Ansatz auch funktionieren.

    private static final Map<Level, String> PREFIXES = UnifiedMap.<Level, String>newMap()
    .withKeyValue(Level.CONFIG, "[config]")
    .withKeyValue(Level.FINE, "[debug]")
    .withKeyValue(Level.FINER, "[debug]")
    .withKeyValue(Level.FINEST, "[trace]")
    .withKeyValue(Level.INFO, "[info]")
    .withKeyValue(Level.SEVERE, "[error]")
    .withKeyValue(Level.WARNING, "[warning]")
    .asUnmodifiable();

    Sollten Sie bemerken, gibt es keine Notwendigkeit für die static-block in beiden Fällen.

    Hinweis: ich bin ein committer für Eclipse Sammlungen.

    InformationsquelleAutor Donald Raab
  6. 0

    Wenn eine Sammlung ist die Letzte, Sie können nicht legen Sie ein neues Objekt hinein.
    Allerdings ist es immer noch möglich ist, Elemente hinzufügen oder entfernen, um das gleiche Objekt.

    Wenn du es unveränderbar, Sie können auch Elemente hinzufügen oder entfernen, um die Sammlung.
    Daher ist es immer ratsam, um die Sammlung Unveränderbar, anstatt nur zu halten, endgültig.

    InformationsquelleAutor Johnson Carneiro
Schreibe einen Kommentar