2011-09-15 33 views
5

He estado buscando algún código desarrollado por un grupo off-shore. Veo al menos una "interfaz constante" por módulo definido. Ejemplo (no real):¿Cuáles son las alternativas más elegantes a las interfaces constantes?

public interface RequestConstants{ 
    //a mix of different constants(int,string,...) 
    public static final int MAX_REQUESTS = 9999; 
    public static final String SAMPLE_REQUEST = "Sample Request"; 
} 

por mi entendimiento es un anti-patrón ya que estos no hace ninguna utilidad en tiempo de ejecución, y se deben evitar o abordar de una manera diferente. ¿Cuáles son las maneras elegantes de representar esto? ¿Se puede usar enums en su lugar?

+0

¡Guau! voto abajo ¿pero por qué? –

+0

Recomiendo probar rigurosamente la funcionalidad de su programación y no preocuparse por problemas como este hasta que encuentre funcionalidades rotas. – emory

Respuesta

1

Enum probablemente no sea una buena idea a menos que todos los parámetros estén estrechamente relacionados. Con los dos parámetros en su ejemplo, diría que no están lo suficientemente relacionados como para calificar como una enumeración.

Pero no es necesariamente una mala idea incluir una clase/interfaz de constantes como esta. Tiene la ventaja de ser centralizado, lo que significa que este elemento de configuración se puede mover fácilmente fuera del programa, por ejemplo, a un archivo de propiedades, un decodificador de línea de comandos, una base de datos o incluso una interfaz de socket, con un impacto mínimo en las otras clases Realmente es una cuestión de qué dirección tomará el diseño.

A menos que esté pensando en seguir por ese camino, sin embargo, diría que las finales estáticas en las clases donde se usan los parámetros respectivos es el camino a seguir, como ya se ha sugerido.

+0

Estoy de acuerdo. Usar enums y/o clases en lugar de interfaces puede romper el código existente. No lo veo tan serio como un antipatrón. – emory

0

Convierta la interfaz en una clase final con un constructor private.

+1

Sería bueno ... –

6

prefiero poner constantes de la clase donde se hacen son más relevantes, y luego si tienen para referirse a ellos en otro lugar, simplemente hacerlo - posiblemente usando las importaciones estáticas si eso tiene sentido (por ejemplo, para Math.PI).

La única razón real para poner constantes en las interfaces fue para permitirle "implementar" la interfaz sin método y obtener acceso a las constantes a través de sus nombres simples sin ninguna calificación adicional. Las importaciones estáticas eliminan esa razón.

+1

Las importaciones estáticas no alcanzan exactamente el efecto deseado en algunas circunstancias. Si tengo varias clases en un archivo .java (por ejemplo, archivos anidados), cada clase puede tener su propio conjunto de constantes y algunas de ellas podrían tener nombres superpuestos. Usar una importación estática significaría un conflicto. – emory

+0

@emory: cierto. Por otro lado, no me gustaría utilizar el truco de la interfaz en ese caso de todos modos, tener el mismo nombre de constante que significa cosas diferentes en el mismo archivo me parece una mala idea. –

+0

@Jon Skeet - "La única razón real para poner constantes en las interfaces era permitirle" implementar "la interfaz sin método y obtener acceso a las constantes a través de sus nombres simples" - Suena muy interesante. Pero, ¿no es esa una peor práctica desde el punto de vista de OO? ¿Cómo se relaciona eso en el mundo real? - gracias por tu respuesta. –

0

Utilice la clase final no instanciable, es decir, una con un constructor privado.

+1

... si los votos abajo en estas respuestas han sido explicados. –

Cuestiones relacionadas