variable una tipos salida qué que para modificadores metodos formato entrada declarar declara datos cómo constantes acceso java coding-style constants code-organization

tipos - que es una variable en java



Forma ideal de organizar constantes de Java. (8)

Tenemos un gran proyecto basado en un antiguo jdk 1.4. Hemos migrado la aplicación web a JDK 1.6, pero aún existen muchas prácticas ineficientes y mal diseño en el código.

Una de las principales clases de java de más de 2500 líneas de código en un solo archivo java. Tantos archivos como estos.

En un intento por refactorizar las clases, comencé eliminando constantes y colocando constantes en diferentes archivos Constants.java. pero como hay tantas constantes en toda la aplicación, el archivo de constantes tiene el riesgo de crecer a proporciones gigantescas.

Apreciaría los comentarios sobre qué estrategia están adoptando los desarrolladores para mantener el código limpio y mantenible.


¡Poner todas las constantes en un solo archivo es una idea terrible! Especialmente el anti-patrón súper-constante donde todas las constantes están en una Interface que cada clase tiene que implement . 10 maneras 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 importa este archivo de constantes de uber. Las cosas que van juntas deben estar juntas en un Enum o al menos en la Class que las usa como argumentos de sus métodos para que cuando se cambien, sepan cómo hacer un análisis de impacto fácilmente.

Imagine las constantes de Color combinadas con DaysOfTheWeek constantes de DaysOfTheWeek combinadas con otras constantes de dominio de negocios y habrá cientos si no miles de estas cosas en un solo archivo. ¿Cómo se puede considerar una buena idea? En todos los casos no artificiales, un Enum que es un miembro public inner de una Class es una mejor solución.

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

Al diseñar y refactorizar siempre debes:

Esfuércese por lograr una alta cohesión , esto significa mantener las cosas relacionadas lo más cerca posible.

Esfuércese por conseguir un acoplamiento suelto; esto significa que no permita que las cosas no relacionadas se filtren en otros ámbitos no relacionados.

¡Tratar de auto-documentar el código mantenible, docenas o cientos de declaraciones private static final String/int mezcladas no se ajusta a esta definición según el estándar de nadie!

En 2012, las constantes de estilo C son una solución deficiente cuando ahora tiene Enum como herramienta, debe concentrarse en convertir tantos de estos grupos de Constantes en Enum sea ​​posible. Enum es de tipo seguro y puede tener otros atributos, propiedades y comportamientos adjuntos para que sean intelligent . Ese es el camino para bajar.



Creo que si tiene varios archivos java sobre 2500 LOCs, la decisión sobre dónde colocar las constantes debería ser el menor de sus problemas. Debe tener una idea clara de cómo se verá el sistema reestructurado. Probablemente esto sea mucho más difícil que decidir dónde pegar las constantes y otras consideraciones sintácticas, pero debe hacerse primero.


Mantenga sus constantes en la clase con la que están relacionados, 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.

Mantener las cosas relacionadas entre sí .

Y también puedes convertirlos a Enums cuando sea posible / útil (pero eso puede requerir un poco de refactorización).


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

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

Ahora, en cada subpaquete de su aplicación, cree un archivo de Constantes que solo estará relacionado con el subpaquete. Así que si tuvieras. un subpaquete llamado Inicio de sesión solo pone constantes relacionadas con el inicio de sesión allí. Pero la clave es extenderse fuera de BaseConstants. De esta manera, puede ver todas las constantes globales en el selector de IDE, pero cuando abre el archivo solo ve las constantes de sus paquetes. Dicho esto, creo que los archivos constantes pueden ser realmente pesados, duplicar valores y ser 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 tus otros paquetes crea 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 escribe "MyPackageConstants". Debería ver todas las constantes para toda la aplicación.


Nunca he oído hablar de poner todas las constantes en un solo archivo java. La mejor manera es poner las constantes acosadas con las clases en sí mismas, pero nombrarlas con mayúscula y guiones bajos como este: EXAMPLE_CONSTANT


Para alguien que está visitando esta página.

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

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

Actualizaciones:

Como práctica recomendada, es mejor usar la Clase. (Ver comentarios. Gracias Kepler.)

public final class Constants { private Constants() { // restrict instantiation } public static final double PI = 3.14159; public static final double PLANCK_CONSTANT = 6.62606896e-34; } import static Constants.PLANCK_CONSTANT; import static Constants.PI; public class Calculations { public double getReducedPlanckConstant() { return PLANCK_CONSTANT / (2 * PI); } }


Solo poner constantes en un archivo Constant.java no tiene sentido en mi opinión (solo aleja el problema). 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, usar enumeraciones también puede ser útil (y las mejores prácticas).

edición: para ser precisos, en realidad trabajo con la aplicación Java ME, así que es solo una manera de "imitar" las enums que no puedo tener, con un "vocabulario controlado" en clases abstractas (echo de menos todas las características de Java EE .. .)