Frage

Ich habe so gesehen Beispiele:

public class MaxSeconds {
   public static final int MAX_SECONDS = 25;
}

und angenommen, dass ich eine Constants Klasse Konstanten zu wickeln haben könnte, sie static final zu deklarieren. Ich weiß, dass praktisch keine Java überhaupt und frage mich, ob dies der beste Weg ist, Konstanten zu erstellen.

War es hilfreich?

Lösung

Das ist durchaus akzeptabel, wahrscheinlich sogar der Standard.

(public/private) static final TYPE NAME = VALUE;

Dabei gilt TYPE der Typ ist, NAME ist der Name in allen Kappen mit Unterstrichen für Räume und VALUE ist der konstante Wert;

Ich empfehle setzen sehr NICHT Ihre Konstanten in ihren eigenen Klassen oder Schnittstellen.

Als Randbemerkung: Variablen, die als final deklariert werden und wandelbar sind noch geändert werden kann; jedoch kann die variable Punkt nie ein anderes Objekt an.

Zum Beispiel:

public static final Point ORIGIN = new Point(0,0);

public static void main(String[] args){

    ORIGIN.x = 3;

}

Das ist legal und ORIGIN würde dann ein Punkt, an (3, 0) sein.

Andere Tipps

Ich würde sehr davon abraten, eine einzige Konstanten Klasse aufweist. Es kann eine gute Idee zu der Zeit erscheinen, aber wenn die Entwickler sich weigern Konstanten zu dokumentieren und die Klasse wächst nach oben von 500 Konstanten umfassen, die alle überhaupt nicht miteinander verwandt sind (sie ist auf ganz andere Aspekte der Anwendung im Zusammenhang), das im allgemeinen verwandelt sich in die Konstanten-Datei vollständig unlesbar zu sein. Statt dessen:

  • Wenn Sie den Zugriff auf Java 5+ haben, verwenden Sie Aufzählungen, spezifische Konstanten für einen Applikationsbereich zu definieren. Alle Teile des Anwendungsbereiches sollte Aufzählungen beziehen, nicht konstante Werte für diese Konstanten. Sie können eine ENUM ähnlich erklären, wie man eine Klasse deklarieren. Aufzählungen sind vielleicht die meisten (und wohl nur) nützliche Funktion von Java 5 +.
  • Wenn Sie Konstanten, die nur gültig für eine bestimmte Klasse oder einer ihrer Unterklassen sind, erklären sie als entweder oder öffentlich geschützt und auf der Top-Klasse in der Hierarchie platzieren. Auf diese Weise können die Unterklassen diese konstanten Werte zugreifen (und wenn andere Klassen sie über den Zugang der Öffentlichkeit, die Konstanten gelten nicht nur zu einer bestimmten Klasse ... was bedeutet, dass die externen Klassen diese Konstante mit zu fest an die gekoppelt sein kann Klasse, um die konstante)
  • enthalten
  • Wenn Sie eine Schnittstelle mit dem Verhalten definiert haben, aber zurückgegebenen Werten oder Argumentwerte sollten insbesondere sein, ist es perfekt acceptible ist Konstanten auf dieser Schnittstelle zu definieren, so dass andere Implementierer Zugang zu ihnen haben. Vermeiden Sie jedoch eine Schnittstelle zu schaffen nur Konstanten zu halten. Es gerade erstellt genauso schlecht wie eine Klasse werden können Konstanten halten

Es ist eine BAD PRAXIS Schnittstellen zu verwenden, nur Konstanten zu halten (mit dem Namen Konstante Schnittstelle Muster von Josh Bloch). Hier ist, was Josh rät:

  

Wenn die Konstanten stark gebunden an   eine vorhandene Klasse oder Schnittstelle, Sie   sollten sie in die Klasse hinzufügen oder   Schnittstelle. Zum Beispiel kann die gesamte   boxed numerische primitive Klassen,   wie Integer und Double, Export   MIN_VALUE und MAX_VALUE Konstanten. Wenn   die Konstanten sind am besten betrachtet als   Mitglieder eines Aufzählungstyp, Sie   sollte sich mit einem exportieren Enum   Art. Andernfalls sollten Sie den Export   Konstanten mit einem nichtinstanziierbare   Utility-Klasse.

Beispiel:

// Constant utility class
package com.effectivejava.science;
public class PhysicalConstants {
    private PhysicalConstants() { }  // Prevents instantiation

    public static final double AVOGADROS_NUMBER   = 6.02214199e23;
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    public static final double ELECTRON_MASS      = 9.10938188e-31;
}

über die Namenskonvention:

  

Nach Konvention solche Felder haben Namen   bestehend aus Großbuchstaben, mit   Worte von Unterstrichen getrennt. Es ist   entscheidend, dass diese Felder enthalten   entweder primitive Werte oder Referenzen   auf unveränderliche Objekte.

Effective Java (2. Auflage), wird empfohlen, dass Sie Aufzählungen anstelle von statischen Ints für Konstanten verwenden.

Es gibt eine gute Zuschreibung auf Aufzählungen in Java hier: http://java.sun.com/j2se/1.5 0,0 / docs / guide / language / enums.html

Man beachte, dass am Ende dieses Artikels die Frage gestellt ist:

  

Also, wenn Sie verwenden sollen Aufzählungen?

Mit einer Antwort von:

  

Jedes Mal, wenn Sie einen festen Satz von Konstanten müssen

Just vermeiden eine Schnittstelle mit:

public interface MyConstants {
    String CONSTANT_ONE = "foo";
}

public class NeddsConstant implements MyConstants {

}

Es ist verlockend, aber gegen Verkapselung und verwischt die Unterscheidung von Klassendefinitionen.

Ich verwende folgenden Ansatz:

public final class Constants {
  public final class File {
    public static final int MIN_ROWS = 1;
    public static final int MAX_ROWS = 1000;

    private File() {}
  }

  public final class DB {
    public static final String name = "oups";

    public final class Connection {
      public static final String URL = "jdbc:tra-ta-ta";
      public static final String USER = "testUser";
      public static final String PASSWORD = "testPassword";

      private Connection() {}
    }

    private DB() {}
  }

  private Constants() {}
}

als zum Beispiel verwende ich Constants.DB.Connection.URL konstant zu erhalten. Es sieht mehr „Objekt oriently“ wie für mich.

Erstellen von static final Konstanten in einer separaten Klasse können Sie in Schwierigkeiten geraten. Die Java-Compiler werden diese tatsächlich optimieren und den tatsächlichen Wert der Konstanten in jede Klasse platzieren, die sie verweist.

Wenn Sie später die ‚Konstanten‘ Klasse ändern und Sie nicht ein hartes Wieder kompilieren auf anderen Klassen tun, der diese Klasse verweisen, werden Sie mit einer Kombination aus alten und neuen Werten aufzuwickeln verwendet wird.

Statt darüber nachzudenken, diese als Konstanten, denken Sie an sie als Konfigurationsparameter und eine Klasse erstellen, um sie zu verwalten. Sind die Werte nicht endgültig, und sogar als Getter verwendet wird. In der Zukunft, wie Sie einige dieser Parameter zu bestimmen, die tatsächlich durch den Benutzer oder Administrator konfiguriert sein sollte, wird es viel einfacher sein, zu tun.

Die Nummer eins Fehler können Sie eine global zugängliche Klasse mit einem generischen Namen, wie Konstanten genannt machen erstellt. Dies einfach wird mit Müll übersät, und Sie verlieren alle Fähigkeit, herauszufinden, was Teil des Systems, diese Konstanten verwendet.

Stattdessen sollten Konstanten in die Klasse gehen, die sie „besitzt“. Haben Sie eine Konstante genannt TIMEOUT haben? Es sollte wahrscheinlich die Kommunikation () oder Verbindung () der Klasse gehen. MAX_BAD_LOGINS_PER_HOUR? Geht in Benutzer (). Und so weiter und so fort.

Die andere mögliche Anwendung ist Java .properties-Dateien, wenn „Konstanten“ können zur Laufzeit festgelegt werden, aber nicht so leicht den Benutzer austauschbar. Sie können diese nach oben in Ihrem .jars verpacken und sie mit der Klasse Resource verweisen.

Das ist der richtige Weg zu gehen.

Im Allgemeinen sind Konstanten nicht gehalten in separaten "Constants" Klassen, weil sie nicht auffindbar sind. Wenn die Konstante auf die aktuelle Klasse relevant ist, halten sie es hilft, den nächsten Entwickler.

Was ist eine Aufzählung?

Ich ziehe es Getter anstatt Konstanten zu verwenden. Diese Getter könnten konstante Werte zurückgeben, z.B. public int getMaxConnections() {return 10;}, aber alles, was die Konstante braucht, wird ein Getter gehen.

Ein Vorteil ist, dass, wenn Ihr Programm die Konstante entwächst - Sie finden, dass sie konfigurierbar sein muss -. Sie können einfach ändern, wie die Getter die Konstante zurück

Der andere Vorteil ist, dass, um die Konstante zu ändern Sie müssen nicht alles neu kompilieren, die es verwendet. Wenn Sie ein statisches letztes Feld verweisen, wird der Wert dieser Konstante in jeden Bytecode kompiliert, das es verweist.

Ich bin damit einverstanden, dass über eine Schnittstelle ist nicht der Weg zu gehen. dieses Muster zu vermeiden hat sogar einen eigenen Artikel (# 18) in Blochs Effective Java .

Ein Argument Bloch macht gegen die konstante Schnittstelle Muster ist, dass die Verwendung von Konstanten ist eine Implementierung Detail, aber die Implementierung einer Schnittstelle, sie zu nutzen macht, dass die Umsetzung Detail in Ihrer exportierten API.

Das public|private static final TYPE NAME = VALUE; Muster ist ein guter Weg, um eine Konstante zu deklarieren. Ich persönlich denke, es ist besser, eine eigene Klasse zu verhindern, dass alle Ihrer Konstanten Hause, aber ich habe nie einen Grund dies nicht zu tun, andere als persönliche Vorlieben und Stil.

gesehen

Wenn Sie Ihre Konstanten können als Aufzählung gut modelliert werden, sollten Sie die enum Struktur in 1.5 oder höher.

Wenn Sie eine frühere Version als 1.5 verwenden, können Sie immer noch typsichere Aufzählungen mit normalen Java-Klassen abziehen. (Siehe diese Seite für mehr dazu ).

Auf der Grundlage der obigen Ausführungen Ich denke, dies ist ein guter Ansatz die altmodische globale Konstante Klasse (mit public static final Variablen) in ihre ENUM-ähnliche Äquivalent in einer Weise, wie dies zu ändern:

public class Constants {

    private Constants() {
        throw new AssertionError();
    }

    public interface ConstantType {}

    public enum StringConstant implements ConstantType {
        DB_HOST("localhost");
        // other String constants come here

        private String value;
        private StringConstant(String value) {
            this.value = value;
        }
        public String value() {
            return value;
        }
    }

    public enum IntConstant implements ConstantType {
        DB_PORT(3128), 
        MAX_PAGE_SIZE(100);
        // other int constants come here

        private int value;
        private IntConstant(int value) {
            this.value = value;
        }
        public int value() {
            return value;
        }
    }

    public enum SimpleConstant implements ConstantType {
        STATE_INIT,
        STATE_START,
        STATE_END;
    }

}

So dann kann ich verweisen sie mögen:

Constants.StringConstant.DB_HOST

Ein gutes objektorientiertes Design sollte nicht viele öffentlich zugänglichen Konstanten müssen. Die meisten Konstanten sollten in der Klasse gekapselt werden, dass sie ihre Arbeit tun muss.

Es gibt eine gewisse Meinung, dies zu beantworten. Zu Beginn sind Konstanten in Java allgemein als öffentliche, statische und final deklariert. Im Folgenden sind die Gründe:

public, so that they are accessible from everywhere
static, so that they can be accessed without any instance. Since they are constants it
  makes little sense to duplicate them for every object.
final, since they should not be allowed to change

Ich würde nie eine Schnittstelle für ein KONSTANTEN Accessor / Objekt einfach, weil Schnittstellen verwenden werden in der Regel umgesetzt werden erwartet. Wäre das nicht komisch aussehen:

String myConstant = IMyInterface.CONSTANTX;

Stattdessen würde ich zwischen ein paar verschiedene Möglichkeiten, basierend auf einigen kleinen Kompromisse, wählen und so hängt es davon ab, was Sie brauchen:

1.  Use a regular enum with a default/private constructor. Most people would define 
     constants this way, IMHO.
  - drawback: cannot effectively Javadoc each constant member
  - advantage: var members are implicitly public, static, and final
  - advantage: type-safe
  - provides "a limited constructor" in a special way that only takes args which match
     predefined 'public static final' keys, thus limiting what you can pass to the
     constructor

2.  Use a altered enum WITHOUT a constructor, having all variables defined with 
     prefixed 'public static final' .
  - looks funny just having a floating semi-colon in the code
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you still have to put explicit 'public static final' before each variable
  - drawback: not type-safe
  - no 'limited constructor'

3.  Use a Class with a private constructor:
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you have to put explicit 'public static final' before each variable
  - you have the option of having a constructor to create an instance
     of the class if you want to provide additional functions related
     to your constants 
     (or just keep the constructor private)
  - drawback: not type-safe

4. Using interface:
  - advantage: you can JavaDoc each variable with an explanation
  - advantage: var members are implicitly 'public static final'
  - you are able to define default interface methods if you want to provide additional
     functions related to your constants (only if you implement the interface)
  - drawback: not type-safe
  

Was ist der beste Weg, Konstanten in Java zu implementieren?

Ein Ansatz, den wir wirklich vermeiden sollten, :. Schnittstellen Konstanten definieren

speziell eine Schnittstelle Erstellen von Konstanten zu erklären, ist wirklich das Schlimmste, was: es ist der Grund, warum besiegt Schnittstellen entwickelt wurden. Definieren Methode (n) Vertrag

Auch wenn eine Schnittstelle existiert bereits einen besonderen Bedarf zu adressieren, die Konstanten in ihnen erklärt wirklich Sinn, nicht als Konstanten sollten nicht Teil der API und den Vertrag zu Client-Klassen zur Verfügung gestellt werden.


Zur Vereinfachung haben wir im Großen und Ganzen 4 gültige Ansätze .

Mit static final String/Integer Feld:

  • 1) eine Klasse verwenden, die Konstanten im Innern aber nicht nur erklärt.
  • 1 Variante) Erstellen einer Klasse gewidmet nur Konstanten deklarieren.

Mit Java 5 enum:

  • 2), um die ENUM in einer verwandten Zweck Klasse (so als verschachtelte Klasse deklariert).
  • 2-Variante), um die ENUM als eigenständige Klasse erstellen (so in seiner eigenen Klasse-Datei definiert).

TLDR: Welches ist die beste Art und Weise ist, und wo die Konstanten lokalisieren

In den meisten Fällen sind der Enum Weg ist wahrscheinlich feiner als der static final String/Integer Weg und ich persönlich glaube, dass die Art und Weise static final String/Integer sollte nur verwendet werden, wenn wir gute Gründe haben, nicht Aufzählungen zu verwenden.
Und darüber, wo wir die konstanten Werte erklären sollten, die Idee ist, zu suchen, ob es eine einzige bestehende Klasse, die einen spezifischen und starken funktionalen Zusammenhalt mit konstanten Werten besitzt. Wenn wir eine solche Klasse zu finden, sollten wir es als Konstanten Halter verwenden . Andernfalls sollte die Konstante zu keiner bestimmten Klasse zugeordnet werden.


static final String / static final Integer gegen enum

Aufzählungen Nutzung ist wirklich eine Art und Weise zu stark berücksichtigt.
Aufzählungen haben einen großen Vorteil gegenüber String oder Integer konstantes Feld.
Sie setzen eine stärkere Zusammenstellung Einschränkung. Wenn Sie eine Methode definieren, die die ENUM als Parameter nimmt, kann man nur einen ENUM-Wert in der ENUM-Klasse definiert übergeben (oder null).
Mit String und Integer können Sie sie mit beliebigen Werten von kompatibelem Typ ersetzen und die Zusammenstellung wird in Ordnung sein, auch wenn der Wert nicht eine definierte Konstante in den static final String / static final Integer Feldern ist.

Zum Beispiel unter zwei Konstanten in einer Klasse als static final String Felder definiert:

public class MyClass{

   public static final String ONE_CONSTANT = "value";
   public static final String ANOTHER_CONSTANT = "other value";
   . . .
}

Hier ist eine Methode, die eine dieser Konstanten als Parameter haben erwartet:

public void process(String constantExpected){
    ...    
}

Sie können es auf diese Weise aufrufen:

process(MyClass.ONE_CONSTANT);

oder

process(MyClass.ANOTHER_CONSTANT);

Aber keine Kompilierung Einschränkung verhindert, dass Sie es auf diese Weise aufrufen:

process("a not defined constant value");

Sie würden die Fehler nur zur Laufzeit und nur dann, wenn Sie einen Scheck auf dem übertragenen Wert zu einem Zeitpunkt zu tun.

Mit Enum, Schecks werden nicht als Client benötigt nur einen Enum-Wert in einem Enum-Parameter übergeben werden konnte.

Zum Beispiel, hier zwei in einer Enum-Klasse definierten Werte (so konstant aus der Box):

public enum MyEnum {

    ONE_CONSTANT("value"), ANOTHER_CONSTANT(" another value");

    private String value;

    MyEnum(String value) {
       this.value = value;
    }
         ...
}

Hier ist eine Methode, die eine dieser Enum-Werte als Parameter haben erwartet:

public void process(MyEnum myEnum){
    ...    
}

Sie können es auf diese Weise aufrufen:

process(MyEnum.ONE_CONSTANT);

oder

process(MyEnum.ANOTHER_CONSTANT);

Aber die Zusammenstellung werden Sie nie auf diese Weise von Aufrufen es zulassen:

process("a not defined constant value");

Wo sollen wir erklären die Konstanten?

Wenn Ihre Anwendung eine einzige vorhandene Klasse enthält, die mit den konstanten Werten, die 1) und 2) erscheint intuitiver einen spezifischen und starken funktionalen Zusammenhalt besitzt.
Im Allgemeinen ist es erleichtert die Verwendung der Konstanten, wenn diese in der Hauptklasse deklariert ist, dass sie manipuliert oder dass hat einen Namen sehr natürlich zu erraten, dass wir es im Innern finden.

Zum Beispiel in der JDK-Bibliothek, die exponentiellen und pi konstanten Werte sind in einer Klasse deklariert, die nicht nur konstant Erklärungen (java.lang.Math) erklären.

   public final class Math {
          ...
       public static final double E = 2.7182818284590452354;
       public static final double PI = 3.14159265358979323846;
         ...
   }

Die Kunden Mathematik Funktionen basieren oft auf der Math Klasse. So können sie Konstanten leicht genug und kann auch daran erinnern, wo E und PI auf ganz natürliche Art und Weise definiert sind.

Wenn Ihre Anwendung nicht eine vorhandene Klasse enthält, das einen sehr spezifischen und starken funktionalen Zusammenhalt mit den konstanten Werten hat, die 1-Variante) und die 2-Variante) Möglichkeiten erscheinen intuitive.
Im Allgemeinen ist es nicht erleichtert die Verwendung der Konstanten, wenn diese in einer Klasse deklariert werden, die sie manipuliert, während wir auch 3 oder 4 andere Klassen, die sie so viel wie und nicht einer dieser Klassen manipulieren scheint natürlicher sein als andere Host konstante Werte.
Hier definieren eine benutzerdefinierte Klasse zu halten, nur konstante Werte macht Sinn.
Zum Beispiel in der JDK-Bibliothek wird die java.util.concurrent.TimeUnit Enum nicht in einer bestimmten Klasse deklariert, da es nicht wirklich ein und nur eine JDK bestimmte Klasse ist, die als das intuitivste erscheinen, um es zu halten:

public enum TimeUnit {
    NANOSECONDS {
      .....
    },
    MICROSECONDS {
      .....
    },
    MILLISECONDS {
      .....
    },
    SECONDS {
      .....
    },
      .....
}      

Viele Klassen in java.util.concurrent erklärt nutzen sie: BlockingQueue, ArrayBlockingQueue<E>, CompletableFuture, ExecutorService, ... und wirklich keiner von ihnen scheint angebracht, die Enum zu halten.

eine Konstante ist, irgendeinen Typen, kann durch die Schaffung eine unveränderliche Eigenschaft erklärt wird, dass eine Klasse innerhalb (dh ein Mitglied Variable mit dem final Modifikator). Typischerweise wird der static und public Modifikatoren ebenfalls zur Verfügung.

public class OfficePrinter {
    public static final String STATE = "Ready";  
}

Es gibt zahlreiche Anwendungen, bei denen der Wert einer Konstanten eine Auswahl aus einem n-Tupel angibt (z Aufzählung ) Auswahl. In unserem Beispiel können wir wählen einen Aufzählungstyp zu definieren, die die möglichen Werte zugewiesen (d verbessert Typsicherheit ) werden beschränken:

public class OfficePrinter {
    public enum PrinterState { Ready, PCLoadLetter, OutOfToner, Offline };
    public static final PrinterState STATE = PrinterState.Ready;
}

Eine einzige, allgemeine Konstanten Klasse ist eine schlechte Idee. Konstanten sollten zusammen mit der Klasse gruppiert werden sie am logischsten im Zusammenhang mit.

Rather Variablen jeglicher Art (insbesondere Aufzählungen) als die Verwendung von, ich würde vorschlagen, dass Sie Methoden verwenden. Erstellen Sie eine Methode mit dem gleichen Namen wie die Variable und haben sie geben den Wert Sie den Variablen zugewiesen. Jetzt die Variable löschen und ersetzen Sie alle Verweise auf sie mit Aufrufen an die Methode, die Sie gerade erstellt haben. Wenn Sie das Gefühl, dass die Konstante allgemein genug ist, dass Sie eine Instanz der Klasse nicht erstellen müssen nur, es zu benutzen, dann ist die Konstante Methode einer Klassenmethode machen.

FWIW, sollte ein Timeout in Sekunden Wert wahrscheinlich eine Konfigurationseinstellung sein (lesen Sie in von einer Eigenschaft oder durch Injektion Datei wie im Frühjahr) und nicht eine Konstante ist.

Was ist der Unterschied

1.

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

2.

public class MyGlobalConstants {
    private MyGlobalConstants () {} // Prevents instantiation
    public static final int TIMEOUT_IN_SECS = 25;
}

und Verwendung MyGlobalConstants.TIMEOUT_IN_SECS wo immer wir diese Konstante benötigen. Ich denke, beide sind gleich.

Ich würde die Klasse nicht nennen die gleiche (abgesehen von Gehäuse) als Konstante ... ich mindestens eine Klasse von „Einstellungen“ oder „Werte“ oder „Constants“, wo alle Konstanten haben würde würde leben. Wenn ich eine große Anzahl von ihnen, ich würde gruppiert sie in logischen Konstante Klassen bis (Usersetting, AppSettings usw.)

Um es einen Schritt weiter, können Sie global verwendete Konstanten in einer Schnittstelle platzieren, so dass sie systemweit genutzt werden kann. Z.

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

Aber nicht dann implementieren. beziehen sich auf sie nur direkt im Code über den vollständig qualifizierten Klassennamen.

Für Konstanten, Enum ist eine bessere Wahl IMHO. Hier ist ein Beispiel

public class myClass {

public enum myEnum {
    Option1("String1", 2), 
    Option2("String2", 2) 
    ;
    String str;
            int i;

            myEnum(String str1, int i1) { this.str = str1 ; this.i1 = i }


}

Eine der Art und Weise kann ich es durch eine ‚Global‘ Klasse mit den konstanten Werten zu schaffen und machen Sie einen statischen Import in den Klassen, den Zugriff auf die Konstante benötigen.

static final ist meine Präferenz, ich habe nur eine enum verwenden würde, wenn das Element in der Tat enumerable war.

Ich verwende static final Konstanten zu deklarieren und mit der ALL_CAPS Namensschreibweise gehen. Ich habe schon einige wirklichen Leben Fälle gesehen, wo alle Konstanten gebündelten zusammen in einer Schnittstelle. Einige Beiträge haben zu Recht genannt, dass eine schlechte Praxis, vor allem, weil das ist nicht das, was eine Schnittstelle für die ist. Eine Schnittstelle soll einen Vertrag durchzusetzen und soll nicht eine Stelle setzen unabhängige Konstanten in sein. Sie zusammen in eine Klasse Einlochen, die nicht (durch einen privaten Konstruktor) instanziiert werden können auch in Ordnung ist, wenn die Konstante Semantik zu einer bestimmten Klasse gehört nicht ( n). Ich habe immer eine Konstante in der Klasse, dass es die meisten im Zusammenhang, denn das macht Sinn und ist auch leicht wartbar.

Aufzählungen sind eine gute Wahl einen Wertebereich darstellen, aber wenn Sie eigenständige Konstanten mit einem Schwerpunkt auf dem absoluten Wert zu speichern (zB. Timeout = 100 ms) können Sie nur für den static final Ansatz gehen.

Ich bin damit einverstanden mit dem, was die meisten sagen, es am besten ist, Aufzählungen zu verwenden, wenn mit einer Sammlung von Konstanten handelt. Wenn Sie jedoch die Programmierung sind in Android gibt es eine bessere Lösung: IntDef Annotation .

@Retention(SOURCE)
@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST,NAVIGATION_MODE_TABS})
public @interface NavigationMode {}
public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;
...
public abstract void setNavigationMode(@NavigationMode int mode);
@NavigationMode
public abstract int getNavigationMode();

IntDef Anmerkung zu Aufzählungen in einer einfachen Art und Weise überlegen ist, dauert es deutlich weniger Platz, da es einfach ein Kompilierung-Marker ist. Es ist nicht eine Klasse, noch hat es die automatische String-Konversionseigenschaft.

Es ist Unsitte und schrecklich ANNOYING Praxis Joshua Bloch zitieren, ohne die Grundbodennull Fundamentalismus zu verstehen.

Ich habe nicht gelesen etwas Joshua Bloch, also entweder

  • Er ist ein schrecklicher Programmierer
  • oder die Menschen so weit, den ich finden zitierte ihn (Joshua ist der Name eines Jungen nehme ich an) verwenden einfach sein Material als religiösen Schriften ihrer Software religiösen Ablässe zu rechtfertigen.

Wie in Bibel Fundamentalismus alle biblischen Gesetze können durch

aufsummiert werden
  • Die Liebe der Grund Identität mit ganzem Herzen und ganzem Gemüt
  • Liebe deinen Nächsten wie dich selbst

und so ähnlich Software-Engineering-Fundamentalismus kann durch

aufsummiert werden
  • widmen sich den Boden-Null-Grundlagen mit allen Programmierung Macht und Geist
  • und widmen in Richtung Exzellenz Ihrer Mitmenschen Programmierer, wie Sie es für sich selbst.

Auch unter biblischen fundamentalistischen Kreisen eine starke und vernünftige Folgerung gezogen

  • Erste Liebe selbst. Denn wenn man sich nicht viel lieben, dann ist das Konzept „deinen Nächsten lieben wie dich selbst“ nicht viel Gewicht tragen, denn „wie viel du dich selbst liebst“ ist die Bezugslinie, über dem würden Sie andere lieben.

Und falls Sie nicht respektieren, sich als Programmierer und nur die Aussagen und Prophezeiungen einiger Programmierung Guru-Nath akzeptieren, ohne die Grundlagen in Frage zu stellen, Ihre Angebote und die Abhängigkeit von Joshua Bloch (und dergleichen) ist bedeutungslos. Und deshalb würden Sie tatsächlich keinen Respekt haben für Ihre Mitmenschen Programmierer.

Die Grundgesetze der Software-Programmierung

  • Faulheit ist die Tugend eines guten Programmierers
  • Sie sind Ihre Programmierung das Leben so einfach, wie faul und deshalb so effektiv wie möglich machen
  • Sie sind die Folgen und Eingeweide Ihrer Programmierung so einfach zu machen, wie faul und deshalb so effektiv wie möglich für Ihren Nachbar-Programmierer, die mit Ihnen zusammenarbeiten und Ihre Programmierung Eingeweide abholen.

Schnittstelle-Muster Konstanten ist eine schlechte Angewohnheit ???

Unter welchen Gesetzen grundsätzlich wirksam und verantwortlich Programmierung ist diese religiöse Edikt in den Herbst?

Sie einfach den Wikipedia-Artikel über Interface-Muster Konstanten lesen ( https://en.wikipedia.org/ wiki / Constant_interface ) und die dummen Ausreden heißt es gegen Interface-Muster Konstanten.

  • Whatif-No IDE? Wer auf der Erde als Software-Programmierer würde nicht eine IDE verwenden? Die meisten von uns sind Programmierer, die nicht lieber haben mit Macho aescetic survivalisticism thro Vermeidung der Verwendung einer IDE zu beweisen.

    • Auch - Warten Sie eine Sekunde Befürworter der Mikro-funktionalen Programmierung als Mittel, nicht ein IDE benötigen. Warten Sie, bis Sie meine Erklärung auf Daten-Modell Normalisierung lesen.
  • verpestet die Namespace mit Variablen, die nicht im aktuellen Umfang verwendet? Es könnte Befürworter dieser Meinung sein

    • sind sich nicht bewusst, und die Notwendigkeit, Daten-Modell Normalisierung
  • Mit Schnittstellen für Konstanten Durchsetzung ist ein Missbrauch von Schnittstellen. Die Befürworter einer solchen haben eine schlechte Gewohnheit

    • nicht zu sehen, dass „Konstanten“ muss als Vertrag behandelt werden. Und Schnittstellen verwendet werden, für die Durchsetzung oder auf einen Vertrag Projizieren Compliance.
  • Es ist schwierig, wenn nicht unmöglich Schnittstellen in realisiert Klassen in Zukunft zu konvertieren. Hah .... hmmm ... ???

    • Warum wollen Sie in einem solchen Muster der Programmierung als persistent Auskommen engagieren? IOW, warum widmen sich so ambivalent und schlechte Programmierung Gewohnheit?

Wie auch immer die Ausreden gibt es keine gültige Entschuldigung, wenn es Engineering GRUNDSäTZLICH Effective Software kommt dis zu delegitimieren oder allgemeinMut ist die Verwendung von Schnittstellen-Konstanten.

Es spielt keine Rolle, was die ursprünglichen Absichten und mentale Zustände der Gründerväter, die die Verfassung der Vereinigten Staaten gefertigt waren. Wir konnten die ursprünglichen Absichten der Gründungsväter Debatte aber meinetwegen sind die schriftlichen Aussagen der US-Verfassung. Und es liegt in der Verantwortung eines jeden Bürgers US den schriftlichen literarisch-Fundamentalismus, nicht die ungeschriebenen Gründungs-Absichten, der US-Verfassung zu nutzen.

In ähnlicher Weise ist mir egal, was die „original“ Absichten der Gründer der Java-Plattform und Programmiersprache für die Schnittstelle hatte. Was ich Pflege sind die effektiven Funktionen der Java-Spezifikation bietet, und ich beabsichtige, diese Funktionen in vollen Zügen zu nutzen, um mir die grundlegenden Gesetze der verantwortlichen Software-Programmierung erfüllen zu helfen. Ich interessiere mich nicht, wenn ich wahrgenommen werde, „die Absicht, für deren Schnittstellen zu verletzen“. Ist mir egal, was Gosling oder jemand Bloch sagt über die „richtige Weg, Java zu verwenden“, es sei denn, was sie sagen nicht mein Bedürfnis zu einer effektiven erfüllende Grundlagen verletzen.

Die Fundamental ist Daten-Modell Normalisierungs

Es spielt keine Rolle, wie die Daten-Modell gehostet oder übertragen wird. Ob Sie Schnittstellen oder Aufzählungen oder whatevernots, relationale oder No-SQL, wenn Sie die Notwendigkeit und den Prozess der Datenmodell Normalisierung nicht verstehen.

Wir müssen zuerst das Daten-Modell einer Reihe von Prozessen definieren und normalisieren. Und wenn wir ein kohärentes Datenmodell haben, nur dann können wir verwenden den Prozessablauf seiner Komponenten der funktionalen Verhalten und Prozessblöcken ein Feld oder Bereich der Anwendungen zu definieren. Und nur dann können wir definieren die API jeden Funktionsprozesses.

Auch die Facetten der Datennormalisierung als von EF Codd vorgeschlagen werden jetzt stark in Frage gestellt und stark herausgefordert. z.B. seine Aussage auf 1NF wurde als mehrdeutig, falsch ausgerichtet und stark vereinfachte, kritisiert wie der Rest seiner Aussagen vor allem in dem Aufkommen der modernen Datendienste, Repo-Technologie und die Übertragung ist. IMO, sollten die EF Codd Aussagen vollständig ditched und neuer Satz von mehr mathematisch plausibel Aussagen ausgelegt werden.

Ein eklatanter Fehler von EF Codds und die Ursache seiner Fehlausrichtung zu wirksamem menschlichem Verständnis ist seine Überzeugung, dass menschlich wahrnehmbare mehrdimensionale, wandelbar-Abmessungsdaten effizient thro einen Satz von stückchenweise 2 zweidimensionaler Abbildungen wahrgenommen werden.

Die Grundlagen der Datennormalisierungs

Was EF Codd auszudrücken fehlgeschlagen.

Innerhalb jeder kohärenten Datenmodell, das sind die Reihenfolge der Daten-Modell Kohärenz abgestuft zu erreichen.

  1. Die Einheit und Identität der Dateninstanzen.
    • Design die Granularität der einzelnen Komponentendaten, wobei die Granularität auf einem Niveau ist, wobei jede Instanz einer Komponente eindeutig identifiziert und abgerufen werden.
    • Abwesenheit von Instanz-Aliasing. das heißt, gibt es keine Mittel, mit denen eine Identifizierung mehr als eine Instanz einer Komponente erzeugt.
  2. Das Fehlen von Instanz Übersprechen. Es gibt keine Notwendigkeit, ein oder mehr andere Instanzen eine Komponente zu verwenden, um die Identifizierung eine Instanz einer Komponente zu tragen.
  3. Die Einheit und Identität von Datenkomponenten / Abmessungen.
    • Präsenz der Komponente de-Aliasing. Es muss eine Definition existieren, wobei eine Komponente / Dimension eindeutig identifiziert werden kann. Welches ist die primäre Definition einer Komponente;
    • wo die primäre Definition wird in aussetzt Subdimensionen oder Mitglieds-Komponenten, die nicht zur Folge haben, die nicht Teil einer beabsichtigten Komponente sind;
  4. Einzigartige Mittel der Komponente dealiasing. Da muss man existieren, und nur eine solche Komponente de-Aliasing-Definition für eine Komponente.
  5. Es gibt eine, und nur eine Definition-Schnittstelle oder Vertrag eine übergeordnete Komponente in einer hierarchischen Beziehung von Komponenten zu identifizieren.
  6. Abwesenheit der Komponente Übersprechens. Es existiert nicht the Notwendigkeit, ein Mitglied einer anderen Komponente zu verwenden, um die endgültige Identifizierung einer Komponente beizutragen.
    • In einem solchen Eltern-Kind-Beziehung, muss die Identifizierung Definition eines Elternteils nicht auf einem Teil des Satzes von zugehörigen Komponenten eines Kindes abhängen. Ein Mitglied Bestandteil der Identität eines Elternteil muss die vollständige Kind Identität sein, ohne Rückgriff auf eine oder alle der Kinder eines Kind verweisen.
  7. Preempt bimodale oder multimodale Erscheinungen eines Datenmodells.
    • Wenn es zwei Kandidaten gibt Definitionen eine Komponente, ist es ein deutliches Zeichen, dass es zwei verschiedene Datenmodelle existiert als eine gemischt wird. Das heißt, es ist Inkohärenz bei der Datenmodellebene, oder die Feldebene.
    • Ein Feld von Anwendungen muss man verwenden und nur ein Datenmodell, kohärent.
  8. Erkennen und Komponente Mutation zu identifizieren. Es sei denn, Sie statistische Komponentenanalyse großer Datendurchgeführt haben, werden Sie wahrscheinlich nicht sehen, oder sehen die Notwendigkeit zu behandeln, Komponente Mutation.
    • Ein Datenmodell kann seine einige seiner Komponenten mutieren zyklisch oder nach und nach.
    • Der Modus kann Mitglied Rotation oder Trans-Rotation sein.
    • Mitglied Rotation Mutation unterschiedlicher Austausch von untergeordneten Komponenten zwischen den Komponenten sein könnte. Oder wo völlig neue Komponenten müßten definiert werden.
    • Transpositions Mutation würde manifestieren sich als ein dimensionsElement in einem Attribut Mutieren, vice versa.
    • Jede Mutationszyklus muss als eigenständige Daten-modal identifiziert werden.
  9. Versionize jede Mutation. So dass Sie eine frühere Version des Datenmodells herausziehen kann, wenn vielleicht die Notwendigkeit entstehen eine 8-jährige Mutation des Datenmodells zu behandeln.

In einem Feld oder Gittern von Interwartungskomponente-Anwendungen, da muss man sein und nur eine kohärentes Datenmodell oder besteht ein Mittel für ein Datenmodell / Version selbst zu identifizieren.

Sind Sie fragen wir nach wie vor, wenn wir Interface-Konstanten verwenden könnte? Wirklich?

Es gibt Daten-Normalisierung auf dem Spiel steht mehr Folge als diese banale Frage. Wenn Sie nicht über diese Probleme lösen, die Verwirrung, die Sie Schnittstelle Konstanten denken verursachen vergleichsweise nichts. Zilch.

Aus dem Datenmodell Normalisierung dann bestimmen Sie die Komponenten als Variablen, wie Eigenschaften, wie Vertrag Schnittstelle Konstanten.

Sie dann bestimmen, welche in Wert Injektion geht, Eigenschaft Konfiguration placeholding, Schnittstellen, final Strings, etc.

Wenn Sie die Ausrede, um zu verwenden, eine Komponente leichter zu lokalisieren gegen Interface Konstanten zu diktieren, es bedeutet, dass Sie in der schlechten Gewohnheit sind von nicht daten Modell Normalisierung zu üben.

Vielleicht möchten Sie die Daten-Modell in eine VCS-Release kompilieren. Dass man eine deutlich erkennbare Version eines Datenmodells herausziehen kann.

Werte in Schnittstellen definiert werden vollständig als nicht veränderbare gewährleistet. Und gemeinsam nutzbar. Warum eine Reihe von abschließenden Zeichenfolge in der Klasse von einer anderen Klasse laden, wenn alles, was Sie brauchen, dass Satz von Konstanten ist ??

Warum also nicht diese eine Datenmustervertrag zu veröffentlichen? Ich meine, wenn Sie es kohärent verwalten und normalisieren können, warum nicht? ...

public interface CustomerService {
  public interface Label{
    char AssignmentCharacter = ':';
    public interface Address{
      String Street = "Street";
      String Unit= "Unit/Suite";
      String Municipal = "City";
      String County = "County";
      String Provincial = "State";
      String PostalCode = "Zip"
    }

    public interface Person {
      public interface NameParts{
        String Given = "First/Given name"
        String Auxiliary = "Middle initial"
        String Family = "Last name"
      }
    }
  }
}

Jetzt kann ich meine apps' kontrahiert Etiketten in einer Art und Weise, wie

Referenz
CustomerService.Label.Address.Street
CustomerService.Label.Person.NameParts.Family

Das verwirrt den Inhalt der JAR-Datei? Als Java-Programmierer ist es mir nicht um die Struktur des Glases.

Dies stellt die Komplexität zu OSGi-Laufzeit motiviert Swapping? OSGi ist ein äußerst effizientes Mittel Programmierer zu ermöglichen, in ihren schlechten Gewohnheiten fortzusetzen. Es gibt bessere Alternativen als osgi.

Oder warum nicht? Es gibt keine Leckage von den privaten Konstanten in veröffentlichten Vertrag. Alle privaten Konstanten sollten in eine private Schnittstelle mit dem Namen „Constants“ gruppiert werden, weil ich will nicht für Konstanten suchen haben, und ich bin zu faul, um immer wieder „private final String“ eingeben.

public class PurchaseRequest {
  private interface Constants{
    String INTERESTINGName = "Interesting Name";
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

Vielleicht sogar so aus:

public interface PurchaseOrderConstants {
  public interface Properties{
    default String InterestingName(){
       return something();
    }
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

Das einzige Problem mit dem Interface Konstanten einer Überlegung wert ist, wenn die Schnittstelle implementiert wird.

Dies ist nicht die „ursprüngliche Absicht“ von Schnittstellen? Wie ich über die „ursprüngliche Absicht“ der Gründungsväter kümmern würde die US-Verfassung in Handwerk, anstatt, wie der Oberste Gerichtshof würde interpretiert die geschriebenen Buchstaben der US-Verfassung ???

Schließlich lebe ich im Land der Freien, die wilde und Heimat der Tapferen. Seien Sie mutig, frei sein, sein wild - die Schnittstelle verwenden. Wenn meine Mitmenschen Programmierer verweigern effizient und faul mittels Programmierung zu verwenden, bin ich von der goldenen Regel verpflichtet, meine Programmiereffizienz zu verringern mit ihnen auszurichten? Vielleicht sollte ich auch, aber das ist keine ideale Situation.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top