¿Cuál es la mejor manera de implementar constantes en Java?[cerrado]

StackOverflow https://stackoverflow.com/questions/66066

  •  09-06-2019
  •  | 
  •  

Pregunta

He visto ejemplos como este: 

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

y se supone que yo pudiera tener una Constantes de la clase para ajustar las constantes, se les declara static final.Sé que prácticamente no Java en todo y me pregunto si esta es la mejor manera de crear constantes.

¿Fue útil?

Solución

Es perfectamente aceptable, probablemente incluso el estándar.

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

donde TYPE es el tipo de NAME es el nombre en mayúsculas con espacios, y VALUE es el valor constante;

Yo recomiendo NO poner tu constantes en sus propias clases o interfaces.

Como nota lateral:Las Variables que son declaradas final y son mutables todavía puede ser cambiado;sin embargo, la variable puede nunca apunte a un objeto diferente.

Por ejemplo:

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

public static void main(String[] args){

    ORIGIN.x = 3;

}

Que es legal y ORIGIN sería un punto a (3, 0).

Otros consejos

Yo le aconsejo vivamente en contra de tener una sola clase constantes.Puede parecer una buena idea en el momento, pero cuando los desarrolladores de rechazar el documento de las constantes de la clase y crece hasta abarcar más de 500 constantes que no son todos relacionados entre sí en todos los (que están relacionados con completamente diferentes aspectos de la aplicación), esto generalmente se convierte en el archivo de constantes ser completamente ilegible.Lugar:

  • Si usted tiene acceso a Java 5+, el uso de las enumeraciones para definir sus específicos constantes para un área de aplicación.Todas las partes de la zona de aplicación debe referirse a las enumeraciones, no es constante, valores de estas constantes.Usted puede declarar una enumeración similar a cómo declarar una clase.Las enumeraciones son quizás los más (y, posiblemente, el único) característica útil de Java 5+.
  • Si usted tiene constantes que sólo son válidos para una clase en particular o una de sus subclases, se declaran como protegidas o público y colocarlos en la parte superior de la clase en la jerarquía.De esta manera, las subclases pueden acceder a estos valores constantes (y si otras clases de acceder a ellos a través público, las constantes no sólo son válidos para una clase en particular...lo que significa que las clases externas mediante esta constante puede ser demasiado estrechamente ligado a la clase que contiene el constante)
  • Si usted tiene una interfaz con un comportamiento definido, pero devuelve los valores o los valores de los argumentos debe ser particular, es perfectamente aceptable para definir las constantes de la interfaz para que otros programadores tendrán acceso a ellos.Sin embargo, evitar la creación de una interfaz sólo para mantener constantes:puede llegar a ser tan malo como una clase creada sólo para mantener constantes.

Es un MALA PRÁCTICA el uso de interfaces sólo para mantener constantes (denominado constante de la interfaz de patrón por Josh Bloch).He aquí lo que Josh aconseja:

Si las constantes están fuertemente ligados a una clase existente o de la interfaz, se debe agregar a la clase o la interfaz.Por ejemplo, todos los de la caja numérico primitivo clases, como Integer y Double, exportación MIN_VALUE y MAX_VALUE constantes.Si las constantes se ve mejor como los miembros de un tipo enumerado, que debe de exportación con un enum tipo.De lo contrario, debe exportar el constantes con un no instanciable utilidad de la clase.

Ejemplo:

// 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;
}

Acerca de la convención de nomenclatura:

Por convención, los nombres de los campos consta de letras mayúsculas, con palabras separadas por guiones bajos.Es crítica de que estos campos contienen cualquiera de los valores primitivos o referencias a objetos inmutables.

En cuanto a la eficacia de Java (2ª edición), se recomienda el uso de las enumeraciones en lugar de estático enteros para las constantes.

Hay una buena valoración crítica de las enumeraciones en Java aquí:http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

Tenga en cuenta que al final de ese artículo a la pregunta planteada es:

Así que cuando se debe utilizar enumeraciones?

Con una respuesta de:

En cualquier momento usted necesita un conjunto fijo de las constantes de

Evitar el uso de una interfaz:

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

public class NeddsConstant implements MyConstants {

}

Es tentador, pero viola la encapsulación y difumina la distinción de las definiciones de clase.

Yo uso el siguiente enfoque:

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() {}
}

Que, por ejemplo, yo uso Constants.DB.Connection.URL para obtener la constante.Se ve más "objeto oriently" como para mí.

La creación de static final constantes en una clase separada puede meter en problemas.El compilador de Java realidad optimizar este lugar y el valor real de la constante a cualquier clase a la que hace referencia.

Si más adelante cambia el 'Constantes' de la clase y no hacer un duro volver a compilar en otras clases que hacen referencia a esa clase, vas a terminar con una combinación de viejos y nuevos valores.

En lugar de pensar en estos como constantes, piensa en ellos como los parámetros de configuración y crear una clase para gestionar ellos.Tener los valores que ser no-final, e incluso considerar el uso de los captadores.En el futuro, como determinar que algunos de estos parámetros en realidad debería ser configurable por el usuario o el administrador, será mucho más fácil de hacer.

El número uno de los errores que usted puede hacer es crear un acceso mundial a clase llamada con un nombre genérico, como Constantes.Este simplemente se llena de basura y se pierde toda capacidad para averiguar qué parte de su sistema utiliza estas constantes.

En lugar de ello, las constantes deben ir dentro de la clase que es "dueño" de ellos.¿Tiene usted una constante denominada tiempo de espera?Probablemente debería ir en sus Comunicaciones() o Conexión() de la clase.MAX_BAD_LOGINS_PER_HOUR?Entra en el Usuario().Y así sucesivamente y así sucesivamente.

El otro posible uso es Java .propiedades de los archivos cuando los "constantes" puede ser definido en tiempo de ejecución, pero no es fácil que puede cambiar el propio usuario.Usted puede empaquetar estas en tu .los frascos y se hace referencia a ellos con la Clase resourceLoader.

Ese es el camino correcto a seguir.

Generalmente son constantes no mantenerse en independiente "Constantes" clases debido a que no son detectables.Si la constante es importante para la actual clase, mantenerlos allí ayuda a que el próximo desarrollador.

¿Qué acerca de una enumeración?

Yo prefiero usar los captadores en lugar de constantes.Los captadores pueden devolver valores constantes, por ejemplo, public int getMaxConnections() {return 10;}, pero nada de lo que necesita la constante pasará a través de un captador.

Una de las ventajas es que si el programa crece más que el constante--usted encuentra que necesita ser configurable-sólo puede cambiar la forma de la función de captador devuelve la constante.

La otra ventaja es que en el fin de modificar la constante, no tiene que volver a compilar todo lo que usa.Cuando se hace referencia a un conjunto estático de campo final, el valor de la constante es compilado en cualquier bytecode la que hace referencia.

Estoy de acuerdo en que el uso de una interfaz no es el camino a seguir.Para evitar este patrón tiene incluso su propio elemento (#18) en Bloch del Efectivos De Java.

Un argumento Bloch hace en contra de la interfaz constante patrón es que el uso de constantes es un detalle de implementación, pero la implementación de una interfaz para el uso de ellos expone que la implementación de detalle en su exportado de la API.

El public|private static final TYPE NAME = VALUE; el patrón es una buena manera de declarar una constante.Personalmente, creo que es mejor evitar hacer una clase independiente para albergar a todos sus constantes, pero nunca he visto una razón para no hacerlo, aparte de la preferencia personal y el estilo.

Si tu constantes puede ser bien modelada como una enumeración, considere la posibilidad de la enum estructura disponible en 1.5 o posterior.

Si usted está utilizando una versión anterior a la 1.5, usted todavía puede tirar fuera de typesafe enumeraciones por el uso normal de las clases de Java.(Ver este sitio para más sobre esto).

Basado en los comentarios de arriba, creo que este es un buen enfoque para cambiar la vieja usanza constante global de la clase (teniendo public static final de variables) para su enum-como el equivalente de una manera similar a esto:

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;
    }

}

Entonces, puedo referir que les guste:

Constants.StringConstant.DB_HOST

Un buen diseño orientado a objetos, no debería necesitar muchas disponible públicamente constantes.La mayoría de las constantes deben ser encapsulados en la clase que necesita para hacer su trabajo.

Hay una cierta cantidad de opinión para responder a esta.Para empezar, constantes en java son generalmente declarada pública, static y final.A continuación están las razones:

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

Yo nunca lo haría uso de una interfaz para una de las CONSTANTES de descriptor de acceso/objeto, simplemente porque interfaces en general se espera para ser implementado.No esta mirada divertida:

String myConstant = IMyInterface.CONSTANTX;

En lugar de eso me volvería a escoger entre un par de maneras diferentes, basados en algunas pequeñas concesiones, y por lo que depende de lo que usted necesita:

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

¿Cuál es la mejor manera de implementar constantes en Java?

Un enfoque que realmente debemos evitar :el uso de interfaces para definir constantes.

La creación de una interfaz específicamente para declarar constantes es realmente lo peor :derrota a la razón por la que las interfaces fueron diseñados :definición de método(s) de contrato.

Incluso si una interfaz que ya existe para atender una necesidad específica, declarar las constantes en ellos hacen que realmente no tienen sentido como constantes no debe hacer parte de la API y en el contrato, siempre que el cliente de clases.

Para simplificar, hemos ampliamente los 4 enfoques válidos.

Con static final String/Integer campo :

  • 1) el uso de una clase que declara constantes en el interior, pero no sólo.
  • 1 variante) la creación de una clase dedicada a declarar constantes.

Con Java 5 enum :

  • 2) declarar la enumeración en un fin relacionado con la clase (así como una clase anidada).
  • 2 variante) la creación de la enumeración como una clase independiente (así se define en su propio archivo de clase).

TLDR :Cual es la mejor manera y donde localizar las constantes ?

En la mayoría de los casos, la enumeración es probablemente más fino que el de la static final String/Integer camino y personalmente creo que el static final String/Integer forma en que debe ser utilizado sólo si tenemos buenas razones para no utilizar las enumeraciones.
Y sobre donde se debe declarar la constante de valores, la idea es buscar si existe una sola clase existente que posee un específico y fuerte cohesión funcional con valores constantes.Si nos encontramos con una clase, se debe utilizar como las constantes titular.De lo contrario, la constante debe ser asociado a ninguna clase en particular.

static final String/ static final Integer frente a enum

Las enumeraciones de uso es realmente una manera de que se han considerado seriamente.
Las enumeraciones tienen una gran ventaja sobre String o Integer campo constante.
Se establece una mayor compilación de restricción.Si se define un método que toma el enum como parámetro, sólo puede pasar un valor de enumeración definido en la clase enum(o nulo).
Con String e Integer puede sustituir con cualquier valor de tipo de archivo compatible y la compilación va a estar bien, incluso si el valor no es una constante definida en el static final String/ static final Integer campos.

Por ejemplo, por debajo de los dos constantes definidas en una clase como static final String campos :

public class MyClass{

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

Aquí un método que espera tener una de estas constantes como parámetro :

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

Puede invocar de esta manera :

process(MyClass.ONE_CONSTANT);

o 

process(MyClass.ANOTHER_CONSTANT);

Pero no hay compilación de restricción impide la invocación de esta manera :

process("a not defined constant value");

Usted tendría el error en tiempo de ejecución y sólo si lo hace en un tiempo de un cheque por el valor transmitido.

Con enum, los cheques no son necesarios ya que el cliente sólo podía pasar un valor de enumeración en una enumeración de parámetros.

Por ejemplo, aquí dos valores definidos en una clase enum (de manera constante fuera de la caja):

public enum MyEnum {

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

    private String value;

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

Aquí un método que espera para tener uno de estos valores de enumeración como parámetro :

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

Puede invocar de esta manera :

process(MyEnum.ONE_CONSTANT);

o 

process(MyEnum.ANOTHER_CONSTANT);

Pero la compilación nunca permitirá que a partir de la invocación de esta manera :

process("a not defined constant value");

Donde debemos declarar las constantes ?

Si la aplicación contiene una sola clase existente que posee un específico y fuerte cohesión funcional con los valores constantes, la 1) y la 2) aparecen de forma más intuitiva.
En general, facilita el uso de las constantes si estos son declarados en la clase principal que manipula o que tiene un nombre muy natural suponer que vamos a encontrar dentro.

Por ejemplo, en el JDK de la biblioteca, la exponencial y pi valores constantes se declaran en una clase que declarar no sólo de las declaraciones de constantes (java.lang.Math).

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

Los clientes utilizando las matemáticas funciones se basan a menudo en la Math clase.Así, se puede encontrar constantes con bastante facilidad, y también puede recordar donde E y PI se definen de una manera muy natural.

Si su aplicación no contiene una clase existente que tiene una forma muy específica y fuerte cohesión funcional con los valores constantes, la variante 1) y la variante 2) formas aparecen más intuitiva.
Por lo general, no facilitar el uso de las constantes si estos son declarados en una clase que manipula mientras tenemos también 3 o 4 otras clases que los manipulan como mucho y como no una de estas clases parece ser más natural que otros host valores constantes.
Aquí, la definición de una clase personalizada que contenga sólo los valores constantes tiene sentido.
Por ejemplo, en el JDK de la biblioteca, la java.util.concurrent.TimeUnit la enumeración no es declarado en una clase específica como de que no existe uno y sólo uno de JDK específico de la clase que aparecen como las más intuitiva para que se sostenga :

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

Muchas clases declaradas en java.util.concurrent uso de ellos :BlockingQueue, ArrayBlockingQueue<E>, CompletableFuture, ExecutorService , ...y realmente no es uno de ellos parece más apropiado para contener la enumeración.

Una Constante, de cualquier tipo, puede ser declarada por la creación de una inmutable de la propiedad que dentro de una clase (que es una variable de miembro con el final modificador).Normalmente el static y public modificadores también se proporcionan.

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

Hay numerosas aplicaciones donde la constante de valor indica una selección de una n-tupla (por ejemplo, la enumeración) de opciones.En nuestro ejemplo, podemos elegir para definir un Tipo Enumerado que restringir los posibles valores asignados (es decir,mejora de la tipo de seguridad):

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

Una sola genérico de las constantes de la clase es una mala idea.Las constantes deben ser agrupados con la clase que más se relacionan lógicamente.

En lugar de utilizar variables de cualquier tipo (especialmente de las enumeraciones), me gustaría sugerir que el uso de los métodos.Crear un método con el mismo nombre de la variable y tiene que devolver el valor asignado a la variable.Ahora eliminar la variable y reemplazar todas las referencias a él con las llamadas al método que acaba de crear.Si usted siente que la constante es lo suficientemente genérica para que usted no debería tener que crear una instancia de la clase sólo para usar, a continuación, hacer el constante método un método de clase.

FWIW, el tiempo de espera en segundos valor debería de ser una opción de configuración (leer desde un archivo de propiedades o a través de la inyección como en Primavera) y no una constante.

¿Cuál es la diferencia

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;
}

y el uso de MyGlobalConstants.TIMEOUT_IN_SECS siempre que sea necesario esta constante.Yo creo que ambos son lo mismo.

Yo no llamaría a la clase de la misma (a un lado de la caja) como la constante ...Me gustaría disponer de al menos una clase de "Configuración", o "Valores", o "Constantes", donde todas las constantes de vivir.Si que tiene un gran número de ellos, yo iba de grupo en la lógica constante de clases (UserSettings, AppSettings, etc.)

Para dar un paso más, usted puede colocar utilizado a nivel mundial constantes en una interfaz para que puedan ser utilizados en todo el sistema.E. g.

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

Pero luego no la implementan.Sólo se refieren a ellos directamente en el código a través del nombre de clase completamente calificado.

Para las Constantes de Enumeración es una mejor opción, en mi humilde opinión.Aquí es un ejemplo

public class miclase {

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

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


}

Uno de la manera en que lo hago es por la creación de un 'Global' de la clase con los valores constantes y hacer una estática de importación en las clases que necesitan acceder a la constante.

static final es mi preferencia, yo sólo uso un enum si el elemento fue efectivamente enumerable.

Yo uso static final para declarar constantes y vaya con el ALL_CAPS de nomenclatura de la notación.He visto muy pocos casos de la vida real, donde todas las constantes son agrupados juntos en una interfaz.Un par de posts han llamado con razón que una mala práctica, principalmente porque no es lo que una interfaz para.Una interfaz debe hacer cumplir un contrato y no debe ser un lugar para poner relacionados constantes en.Poner juntos en una clase que no puede ser instanciado (a través de un constructor privado) también está bien si la constante de la semántica no pertenecen a una determinada clase(es).Siempre pongo una constante en la clase que más se relacionan, ya que hace sentido y es también fácilmente mantenible.

Las enumeraciones son una buena opción para representar un rango de valores, pero si usted está almacenando independiente constantes con un énfasis en el valor absoluto (por ejemplo.Tiempo de espera = 100 ms) usted puede ir para el static final enfoque.

Estoy de acuerdo con lo que la mayoría de los que están diciendo, lo mejor es utilizar enumeraciones cuando se trata de una colección de constantes.Sin embargo, si usted está programando en Android hay una solución mejor: IntDef Anotación.

@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 anotación es superior a las enumeraciones en una forma simple, que ocupa mucho menos espacio ya que es simplemente una compilación de marcador de tiempo.No es una clase, ni tiene el automático de conversión de cadena a la propiedad.

Es MAL hábito y terriblemente MOLESTO práctica para citar Joshua Bloch, sin comprender que el cero fundamentalismo.

No he leído nada de Joshua Bloch, por lo que sea

  • él es un terrible programador
  • o de las personas que hasta ahora quien me parece citando a él (Josué es el nombre de un niño supongo) son simplemente el uso de su material como escritos religiosos para justificar su software religiosa indulgencias.

Como en la Biblia el fundamentalismo todas las leyes bíblicas que se pueden resumir en

  • El amor de la Identidad Fundamental con todo tu corazón y con toda tu mente
  • Ama a tu prójimo como a ti mismo

y así, del mismo modo la ingeniería de software fundamentalismo se pueden resumir en

  • dedícate a la tierra-cero fundamentos con toda su programación puede y mente
  • y dedicar hacia la excelencia de sus compañeros programadores como para ti mismo.

También, entre bíblica fundamentalista círculos de un fuerte y razonable corolario es dibujado

  • Primer amor a ti mismo.Porque si no te amas a ti mismo mucho, entonces el concepto de "ama a tu prójimo como a ti mismo" no llevar mucho peso, ya que "¿cuánto te amas a ti mismo" es la línea de referencia sobre el que iba a amar a los demás.

Del mismo modo, si usted no respeta a sí mismo como un programador y aceptar los pronunciamientos y las profecías de algún gurú de la programación-nath, SIN cuestionar los fundamentos, sus citas y la dependencia de Joshua Bloch (y similares) no tiene sentido.Y por lo tanto, que en realidad no tienen ningún respeto por sus compañeros programadores.

Las leyes fundamentales de la programación de software

  • la pereza es la virtud de un buen programador
  • usted debe hacer su programación la vida tan fácil, tan perezoso y por lo tanto tan eficaz como sea posible
  • se tienen que hacer las consecuencias y las entrañas de su programación es tan fácil, tan perezoso y por lo tanto tan eficaz como sea posible para que su vecina-los programadores que trabajan con usted y recoger su programación entrañas.

Interfaz-patrón de constantes es un mal hábito ???

En virtud de qué leyes de, fundamentalmente, eficaz y responsable de la programación que hace este edicto religioso caer en ?

Acabo de leer el artículo de wikipedia sobre la interfaz de patrón constantes (https://en.wikipedia.org/wiki/Constant_interface), y las tontas excusas que los estados en contra de la interfaz-patrón constantes.

  • Whatif-No IDE?Que en la tierra como un programador de software no usar un IDE?La mayoría de nosotros son los programadores que prefieren no tener que demostrar haber machista aescetic survivalisticism thro evitar el uso de un IDE.

    • También - espere un segundo defensores de micro-programación funcional como un medio de no necesitar un IDE.Espere hasta que usted lea mi explicación sobre los datos-modelo de normalización.

  • Contamina el espacio de nombres con variables no se utiliza en el ámbito actual?Podría ser que apoyan esta opinión

    • no son conscientes de, y la necesidad de datos-modelo de normalización

  • El uso de interfaces para el cumplimiento de las constantes es un abuso de las interfaces.Los defensores de tales, tienen la mala costumbre de

    • no ver que "constantes" deben ser tratadas como un contrato.Y las interfaces se utilizan para hacer cumplir o proyectar el cumplimiento de un contrato.

  • Es difícil, si no imposible convertir las interfaces implementadas las clases en el futuro.Ja ....hmmm ...???

    • ¿Por qué quieres participar en el patrón de programación como su persistente de los medios de subsistencia?IOW, ¿por qué dedicarse a tal AMBIVALENTE y la mala programación hábito ?

Lo de las excusas, NO hay ninguna EXCUSA VÁLIDA cuando se trata FUNDAMENTALMENTE de EFECTIVO de ingeniería de software para deslegitimar o, en general, desalentar el uso de la interfaz de constantes.

No importa lo que el original intenciones y estados mentales de los padres fundadores de los que redactaron la Constitución de los Estados unidos fueron.Podemos debatir el original de las intenciones de los padres fundadores, pero todo lo que la atención es que las declaraciones escritas de la Constitución de los estados unidos.Y es responsabilidad de cada ciudadano de los EE.UU. para explotar la escritura literaria-fundamentalismo, no la no escrita de la fundación-de las intenciones, de la Constitución de los estados unidos.

Del mismo modo, no me importa lo que la "original" de las intenciones de los fundadores de la plataforma de Java y el lenguaje de programación tenido para la interfaz.Lo que me importa son las eficaces características de la especificación de Java proporciona, y tengo la intención de aprovechar todas las características al máximo para que me ayude a cumplir con las leyes fundamentales de la responsable de programación de software.No me importa si soy percibido a "violar la intención de interfaces".No me importa lo que Gosling o alguien Bloch dice acerca de la "forma correcta de usar Java", a menos que lo que dicen no violar mi necesidad para el EFECTIVO cumplimiento de los fundamentos.

La Fundamental es la de Datos-Modelo de Normalización

No importa cómo sus datos-modelo es alojado o transmitido.Ya sea que utilice o de las interfaces de las enumeraciones o whatevernots, relacional o no-SQL, si usted no entiende la necesidad y el proceso de datos-modelo de normalización.

Primero debemos definir y normalizar los datos-modelo de un conjunto de procesos.Y cuando tenemos una coherente de datos-modelo, SÓLO entonces podemos utilizar el flujo de proceso de sus componentes para definir el comportamiento funcional y de procesos de bloques de un campo o ámbito de aplicaciones.Y sólo entonces podemos definir la API de cada proceso funcional.

Incluso las facetas de la normalización de datos, como el propuesto por EF Codd ahora está severamente cuestionada y severamente-desafió.por ejemplo,su declaración en 1NF ha sido criticado como un ser ambiguo, desalineado y sobre-simplificado, como el resto de sus declaraciones, especialmente en el advenimiento de los modernos servicios de datos, repositorios de la tecnología y de la transmisión.De la OMI, la EF Codd declaraciones deben ser completamente descartada y el nuevo conjunto de más matemáticamente plausible declaraciones de ser diseñado.

Una falla evidente de EF Codd y la causa de su desalineación eficaz de la comprensión humana es su creencia de que humanamente perceptible multi-dimensional, mutable-datos de dimensión puede ser percibido de manera eficiente mediante un conjunto de parciales 2-dimensional de las asignaciones.

Los Fundamentos de la Normalización de Datos

Lo que EF Codd no pudo expresar.

Dentro de cada coherente de datos-modelo, estos son los secuencial de orden gradual de datos-modelo de coherencia a lograr.

  1. La Unidad y la Identidad de instancias de datos.
    • el diseño de la granularidad de los datos de cada componente, la cual a su granularidad se encuentra en un nivel donde cada instancia de un componente pueden ser identificados y recuperados.
    • la ausencia de la instancia de aliasing.es decir, no existen medios por el cual una identificación produce más de una instancia de un componente.
  2. La ausencia de la instancia de la interferencia.No existe la necesidad de la utilización de uno o más instancias de un componente para contribuir a la identificación de una instancia de un componente.
  3. La unidad y la identidad de los datos de los componentes o dimensiones.
    • Presencia de componente de suavizado.Debe existir una definición de la cual un componente/dimensión puede ser identificada.Que es la principal definición de un componente;
    • donde la principal definición de no exponer al sub-dimensiones de miembros o componentes que no son parte de un componente;
  4. El único medio de componente dealiasing.No debe existir el uno, y sólo uno de ellos, el componente de-aliasing definición de un componente.
  5. Existe uno, y sólo uno, de definición de interfaz o contrato para identificar un componente principal en una relación jerárquica de los componentes.
  6. Ausencia de componente de interferencia.No existe la necesidad de la utilización de un miembro de otro componente para contribuir a la definitiva identificación de un componente.
    • En una relación de padre-hijo, la identificación de la definición de un padre no debe depender de parte del conjunto de los miembros componentes de un niño.Un miembro componente de un padre de la identidad debe ser la completa hijo de identidad sin tener que recurrir a hacer referencia a cualquier o todos los niños de un niño.
  7. Adelantarse bi-modal o multi-modal de las apariencias de una base de datos-modelo.
    • Cuando existe dos candidatos definiciones de un componente, es un signo evidente de que existe dos datos diferentes modelos que se mezclen como uno.Que significa que no hay incoherencia en los datos-nivel de modelo, o el nivel de campo.
    • Un campo de las aplicaciones deben usar sólo uno de los datos-modelo, de manera coherente.
  8. Detectar e identificar los componentes de la mutación.A menos que usted haya realizado estadístico de análisis de los componentes de datos de gran tamaño, probablemente no se ven, o ven la necesidad de tratar, componente de la mutación.
    • De datos-modelo tiene sus algunos de sus componentes mutar de forma cíclica o poco a poco.
    • El modo puede ser miembro de la rotación o la transposición de la rotación.
    • Miembro de la rotación de la mutación podría ser distinta de intercambio de componentes entre los componentes.O en forma completamente nueva de los componentes tienen que ser definidos.
    • Transposicional mutación se manifiesta como un dimensional-miembro mutando en un atributo, viceversa.
    • Cada ciclo de la mutación debe ser identificado como un ser distinto de los datos-modal.
  9. Versionize cada mutación.De tal manera que usted puede sacar una versión anterior del modelo de datos, cuando tal vez surge la necesidad de tratar a 8 años de edad de la mutación del modelo de datos.

En un campo o de una red de inter-mantenimiento de componentes de aplicaciones, debe haber uno y sólo uno coherente de datos-modelo o existe un medio para que una base de datos-modelo/versión para identificarse a sí mismo.

Se nos sigue preguntando si podríamos usar Interfaz Constantes?De verdad ?

Hay datos-normalización de los asuntos en juego más importante de este mundano pregunta.SI no soluciona estos problemas, la confusión en la que usted piensa de la interfaz de constantes causa es comparativamente nada.Nada de nada.

A partir de los datos-modelo de normalización, a continuación, determinar los componentes como variables, como propiedades, como la interfaz del contrato de constantes.

Luego de determinar que se pone en valor la inyección, la configuración de propiedades temporales, interfaces, final cadenas, etc.

Si usted tiene que utilizar la excusa de la necesidad de localizar un componente más fácil para dictar en contra de la interfaz de constantes, significa que usted está en el mal hábito de no practicar datos-modelo de normalización.

Tal vez usted desea compilar los datos-modelo en un vcs liberación.Que usted puede sacar un distintivo de identificación personal versión de una base de datos-modelo.

Los valores definidos en las interfaces están completamente seguro de no ser mutable.Y compartible.Por qué cargar un conjunto de final cadenas en su clase a partir de otra clase, cuando todo lo que necesita es que el conjunto de constantes ??

Así que ¿por qué no esta para publicar datos-modelo de contrato?Me refiero a si usted puede manejar y normalizar es coherente, ¿por qué no?...

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"
      }
    }
  }
}

Ahora puedo referencia de mis aplicaciones de contratos de las etiquetas de una manera tal como

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

Esto confunde el contenido del archivo jar?Como programador de Java no me importa acerca de la estructura de la jarra.

Esto presenta la complejidad de osgi motivado por el tiempo de ejecución de intercambio ?Osgi es extremadamente eficiente para permitir a los programadores para continuar en sus malos hábitos.Hay mejores alternativas de osgi.

O ¿por qué no esta?No hay ninguna fuga de privado de las Constantes en el contrato publicado.Todas las constantes deben ser agrupados en una interfaz privada denominada "Constantes", porque yo no quiero tener a la búsqueda de constantes y yo soy demasiado perezoso para escribir de forma repetida "private final String".

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

Tal vez incluso este:

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

El único problema con la interfaz de constantes que vale la pena considerar es cuando la interfaz es implementada.

Esta no es la "intención original" de las interfaces?Me gusta la atención sobre la "intención original" de los padres fundadores, en la elaboración de la Constitución de los estados unidos, en lugar de cómo el Tribunal Supremo iba a interpretar las cartas escritas de la Constitución de los estados unidos ???

Después de todo, yo vivo en la tierra de la libertad, la naturaleza y el hogar de los valientes.Ser valiente, ser libre, ser salvaje - uso de la interfaz.Si mis compañeros de los programadores de rechazar el uso eficiente y perezoso medio de la programación, estoy obligado por la regla de oro para disminuir mi programación de eficiencia para alinear con la suya?Quizás debería, pero que no es una situación ideal.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top