Esta cuestión se puede abordar de variadas formas, pero en este caso te mostramos la resolución más completa para nosotros.
Solución:
Se considera una mala práctica en Java, y en la mayoría de los lenguajes OO, definir una clase simplemente para mantener constantes. Es mucho mejor definir las constantes en una clase a la que están asociadas. Por lo general, hay uno. p.ej
interface MyComponent
/** The default height for a component */
public static final int DEFAULT_HEIGHT = 5;
// other stuff
Si realmente no hay uno, siéntase libre de definir una clase separada.
EDITAR: El key las cosas aqui son:
- Haz que las constantes sean fáciles de encontrar. Si hay un lugar ‘natural’ para colocarlos, colóquelos allí (es decir, la altura predeterminada para los objetos Componente pertenece a la clase Componente).
- No tenga un acoplamiento más alto de lo que necesita. Poner todas sus constantes en una clase de ‘Constantes’ genera un alto acoplamiento, especialmente porque los modificadores posteriores tienden a poner TODAS las constantes en la clase Constantes, ya sea que haya o no otra clase en la que puedan colocarse naturalmente.
- El hecho de que una constante sea utilizada por más de una clase no significa que deba estar en una clase de ‘Constantes’. Si una constante es utilizada por ‘Aplicación’ y clases que utilizan la clase de aplicación luego póngalo en la clase de aplicación. De esa manera no estás aumentando el acoplamiento.
Normalmente, usaría una clase Constantes, o las definiría en las clases donde se usan, a la:
class Constants
public static final int NUM_TRIANGLES = 4;
public static final String SOME_TEXT = "This is a constant";
Entonces te referirías a ellos por:
String inst = Constants.SOME_TEXT;
La forma más común es crear ‘constantes’ en las clases donde las necesita:
class Example
private static final int FILENAME = "test.txt;
En lugar de privado, también puede declararse predeterminado, protegido o público. Aunque se considera un patrón anti OO para definir constantes, es una clase especial de ‘constantes’ (Dios) que almacena constantes para toda la aplicación. Alternativamente, también puede almacenar datos de configuración en un archivo de propiedades de Java, esto no se considera un antipatrón.
Otra opción, que está ganando popularidad rápidamente, es el uso de la Patrón de inyección de dependencia (DI). A menudo, este patrón se usa para objetos dependientes, pero también se puede usar para inyectar valores constantes en objetos. Esto se puede implementar, por ejemplo, con el marco ligero Guice DI de Google:
class Example {
String filename;
@Inject
public Example(@ConfigFilename String filename)
this.filename = filename;
En una clase Binder especial, vinculará un valor a las cadenas anotadas con @ConfigFilename. De esta manera, tiene un acoplamiento mínimo y clases que se pueden probar de forma independiente.
Reseñas y calificaciones del post
Si guardas algún titubeo o forma de acrecentar nuestro enunciado te inspiramos escribir un paráfrasis y con gusto lo analizaremos.