Forma ideal de organizar las constantes de Java

Tenemos grandes proyectos basados en un antiguo jdk 1.4. Hemos migrado la aplicación web a JDK 1.6 pero todavía existen muchas prácticas ineficientes y un diseño incorrecto en el código.Forma ideal de organizar las constantes de Java

En el punto de mayor dolor enormes clases de java 2500+ líneas de código en un único archivo de java. Tantos archivos como estos.

En un intento de refactorizar las clases que había comenzado eliminando constantes y poniendo constantes en diferentes archivos Constants.java. pero dado que hay tantas constantes en toda la aplicación, el archivo de constantes tiene el riesgo de crecer en proporciones enormes.

Agradecería los comentarios sobre qué estrategia están adoptando los desarrolladores para mantener el código limpio y fácil de mantener.

Fuente

2012-02-28 Reg Mem

Una sola clase 'Constantes' suena como un antipatrón.Dividirlos según lo que signifiquen las constantes, o reemplazarlos con enumeraciones cuando corresponda. – millimoose

Como profiláctico, enganche los electrodos a sus desarrolladores que los electrocutarán con algo como LOC * 0.01V de voltaje cada vez que guarden un archivo. – millimoose

¿Qué problemas específicos estás tratando de resolver? ¿Solo el hecho de que los archivos son demasiado grandes? Si eso es todo, entonces el costo de refacturar todo no valdrá la pena. –

Mantenga sus constantes en la clase a la que están relacionadas, no se sienta obligado a extraerlas. Puede limpiar el código de la clase, pero mezclar constantes no relacionadas en un archivo no es una mejora.

Mantenga cosas relacionadas entre sí.

Y también puede convertirlos a Enumeraciones cuando sea posible/útil (pero eso puede requerir algunas refactorizaciones).

Fuente

2012-02-28 16:07:24

Pero siempre existe el riesgo de valores duplicados para las constantes. por ejemplo, el nombre de la tabla "perfil_usuario" se almacena en varias constantes, como EMPLOYER_USER_PROFILE y WEB_USER_PROFILE. etc. –

¿Por qué no puede almacenar el nombre de la tabla como una constante en la clase DAO (la clase para esa tabla), y luego usar esa constante de las otras clases? (requiere declarar la constante como pública) –

@RegMem puede usar el estilo de comprobación y posiblemente otros analizadores de código estático para buscar cadenas idénticas y colocar una advertencia (o una etiqueta 'informativa', como yo uso) en los duplicados. –

Nunca escuché de poner todas las constantes en un solo archivo java. La mejor manera es poner las constantes asociadas a las clases en sí mismas, pero asígneles un nombre mayúscula y guiones bajos como este: EXAMPLE_CONSTANT

Fuente

2012-02-28 16:08:25 Gio

No es mi desventaja, pero el problema es cuando las constantes son necesarias para más de una clase, es decir, las constantes tienen que ver con las interacciones entre clases, no el comportamiento interno de las clases – DNA

@DNA, entonces los pones en la clase más lógica y hacen ellos públicos. –

@owlstead eso es fácil de decir, pero puede que no haya una "clase más obvia". Cuando varias clases dependen de constantes para colaborar, todas comparten esas constantes por igual, y no hay forma de decidir cuál debe contenerlas. Eso no implica que todas las constantes deberían ir en un archivo, por supuesto. Solo que las constantes compartidas podrían ser mejores en una interfaz compartida. Consulte http://docs.oracle.com/javase/6/docs/api/javax/swing/SwingConstants.html, por ejemplo, – DNA

¿Ha intentado utilizar Enums para todas sus constantes? Me han dicho que es la forma preferida desde Java 1.5.

http://docs.oracle.com/javase/1.5.0/docs/guide/language/enums.html

Fuente

2012-02-28 16:10:37

Las entradas son geniales, pero no siempre son capaces de reemplazar las constantes; cada una debe usarse cuando corresponda. –

sólo poner constantes en un archivo Constant.java no hacen Sens en mi opinión (que sólo mueven el problema de distancia). Pero a veces utilizo para reagruparlos para borrar las cosas y usar varios archivos para reagruparlos: DatabaseConstants.java, GraphicConstants.java y así sucesivamente ... y, por supuesto, el uso de enumeraciones también puede ser útil (y la mejor práctica).

editar: para ser precisos, en realidad trabajo con la aplicación Java ME, por lo que es solo una manera de "imitar" las enumeraciones que no puedo tener, con un "vocabulario controlado" en clases abstractas (extraño todo el Java Funciones de EE ...)

Fuente

2012-02-28 16:14:42 Vinze

Estaba pensando en usar esta estrategia, pero mi pregunta no refleja eso porque aún estaba debatiendo si adoptar esa estrategia. Una aplicación que tiene más de 150 objetos únicos del Modelo (no, no estamos usando Spring, o struts, etc.). cada uno de estos objetos modelo tiene una plétora de constantes esparcidas por todos lados, pero es un enfoque –

¡Poner todas las Constantes en un solo archivo es una idea terrible! Especialmente el anti-patrón uber-Constant donde todas las Constantes están en un Interface que cada clase tiene a implement. 10 formas de domingo terrible! ¡Esta fue una mala idea cuando la gente comenzó a hacerlo a principios de los 90 antes de Java! ¡Definitivamente es una mala idea en 2012!

Significa que está mezclando mucha información no relacionada y creando dependencias innecesarias cada vez que importe este archivo uber-Constants. Las cosas que van juntas deben estar juntas en un Enum o al menos en el Class que las usa como argumentos para sus métodos, de modo que cuando se cambien, sepas cómo hacer un análisis de impacto fácilmente.

Constantes de Imagine Color mezcladas con DaysOfTheWeek constantes mezcladas con otras constantes de dominio empresarial y habrá cientos si no miles de estas cosas en un solo archivo. ¿Cómo se puede considerar una buena idea?En cada caso no inventado, un Enum que es un miembro public inner de Class es una mejor solución.

También significa que tiene un único espacio de nombres plano para tratar de crear nombres que no entren en conflicto, entonces no son obvios a qué pertenecen y cómo se deben usar. Este nunca es un ejercicio positivo.

Al diseñar y refactorización que siempre debe:

Esforzarse por una alta cohesión , esto significa mantener las cosas relacionadas tan cerca como sea posible.

Esforzarse por acoplamiento flojo esto significa que no se permite que elementos no relacionados se filtren a otros ámbitos no relacionados.

Esforzarse por auto-documentar el código de mantenimiento, docenas o cientos de declaraciones de private static final String/int, todas juntas no se ajustan a esta definición por el estándar de nadie.

En 2012 las constantes de estilo C son una solución pobre cuando ahora tiene Enum como herramienta, debe centrarse en convertir tantos de estos grupos de constantes en Enum siempre que sea posible. Enum es seguro y puede tener otros atributos y propiedades y comportamientos asociados para hacerlos intelligent. Ese es el camino para bajar.

Fuente

2012-02-28 16:15:12

Quizás sea útil agregar lo que hace que las cosas "estén relacionadas": es probable * que cambien juntas * sin causar (demasiados) cambios a cosas no relacionadas. – reinierpost

(El hecho de que las constantes estén en una 'interfaz', no significa que esa interfaz * tenga * que implementarse). –

-1

Creo que si tiene varios archivos java en más de 2500 LOC, la decisión de dónde colocar las constantes debería ser el menor de sus problemas. Debe formar una imagen clara de cómo se verá el sistema reestructurado. Esto es probablemente mucho más difícil que decidir dónde pegar las constantes y otras consideraciones sintácticas, pero debe hacerse primero sin embargo.

Fuente

2012-02-28 17:44:28

Sí, lo sé, pero con un equipo asustado y interesados (el caso habitual) pensé en comenzando mi "viaje de refactorización" a través del ciclo más corto y el riesgo más bajo. Planeo limpiar la "caca" en el código en múltiples fases –

Ok, para decirlo de otra manera, una vez que tienes un diseño en su lugar, es probable que la pregunta constante desaparezca. –

Para alguien que está visitando esta página.

Si no desea mantener varios archivos constantes, a continuación se muestra la mejor manera de organizarlo.

public interface Constants { 
    public static final String CREATE_USER = "createUser"; 
    // Nested Interface. 
    public interface ProjectConstants { 
     public static final String CREATE_PROJECT = "createProject"; 
     public static final String INVALID_SESSION = "Invalid Session"; 
     // As you know they are implicity public static final. 
    } 
}// Accessed as: 
Constants.ProjectConstants.CREATE_PROJECT

Fuente

2017-03-21 16:16:18 Jajikanth

Sí, hemos empezado a hacerlo, gracias por su respuesta –

Me gustaría compartir un patrón de diseño para las constantes que he visto hace unos años que quizás pueda ayudar.

Comience creando un archivo BaseConstant. Esto mantendrá todas sus constantes globales que podrían usar todos los paquetes.

Ahora, en cada subpaquete de su aplicación, cree un archivo de constantes que solo estará relacionado con el subpaquete. Entonces si tuvieras. un subpaquete llamado Login solo pone constantes relacionadas para iniciar sesión allí. Pero la clave es extenderse desde BaseConstants. de esta manera puede ver todas las constantes globales en el selector IDE, pero cuando abre el archivo solo ve las constantes de su paquete. Dicho esto, creo que los archivos constantes pueden obtener valores muy pesados y duplicados y difíciles de leer.

Esto es lo que quiero decir ..

public class BaseConstants{ 

public static final String GLOBAL1= "GLOBAL string"; 

public static final String GLOBAL2= "another GLOBAL string"; 
}

Ahora en todos sus otros paquetes de crear un archivos como este:

class MyPackageConstants extends BaseConstants{ 

public static final String LOCAL1 = "local String" 
public static final String LOCAL2= "ANOTHER LOCAL string"; 
}

en su IDE cuando se escribe "MyPackageConstants." debería ver todas las constantes para toda la aplicación.

Fuente

2017-06-09 10:45:56 j2emanue

Forma ideal de organizar las constantes de Java

Respuesta

Cuestiones relacionadas