¿Cuál es el uso de constantes de interfaz?

Joshua Bloch, "Effective Java - Programming Language Guide":

El patrón de interfaz constante es un mal uso de las interfaces. Que un la clase utiliza algunas constantes internamente es un detalle de implementación. La implementación de una interfaz constante hace que este detalle de implementación filtrar en la API exportada de la clase. No tiene ninguna consecuencia para el usuarios de una clase que la clase implementa una interfaz constante. En de hecho, puede incluso confundirlos. Peor aún, representa un compromiso: si en una versión futura, la clase se modifica para que ya no necesite para usar las constantes, todavía debe implementar la interfaz para garantizar compatibilidad binaria. Si una clase no final implementa una constante interfaz, todas sus subclases tendrán sus espacios de nombres contaminados por las constantes en la interfaz.

"El patrón de interfaz constante es un mal uso de interfaces "

Quien inventó esta hipótesis, por más gurú que sea, la inventó sobre la base de la necesidad de continuar implementando malos hábitos y prácticas de manera eficiente. La hipótesis se basa en la promoción de la validez de los malos hábitos de diseño de software.

Escribí una respuesta refutación contra esa hipótesis aquí: ¿Cuál es la mejor manera de implementar constantes en Java? explicar el fundamento de esta hipótesis.

Durante 10 años esa pregunta había permanecido abierta, hasta que se cerró dentro de 2 horas después de que publicara mis razones que dejaban de justificar esta hipótesis, exponiendo así la falta de voluntad para el debate de aquellos que se aferran a esta hipótesis equivocada.

Estos son los puntos que expresé contra la hipótesis

• La base para sostener esta hipótesis es la necesidad de métodos y reglas RESTRICTIVAS para hacer frente a los efectos del mal hábitos y metodologías de software.

• Los defensores del sentimiento "El patrón de interfaz constante es un mal uso de las interfaces" son incapaces de proporcionar ninguna otra razón que las causadas por la necesidad de hacer frente a los efectos de esos malos hábitos y prácticas.

• Resolver el problema fundamental.

• Y entonces por qué no hacer pleno uso y explotar cada característica del lenguaje de la estructura del lenguaje Java a su propia conveniencia. No hay Chaquetas Requerir. ¿Por qué inventar reglas para bloquear su estilo de vida ineficaz para discriminar e incriminar estilos de vida más efectivos?

La cuestión fundamental

Es la organización de la información. La información mediadora del proceso, y el comportamiento de esa información debe entenderse primero, junto con las llamadas reglas de negocio, antes de diseñar o complementar soluciones al proceso. Tal método de organización de la información se llamó normalización de datos unos pocos hace décadas.

Entonces solo la ingeniería de una solución es posible porque alinear la granularidad y modularidad de los componentes de una solución con la granularidad y modularidad de los componentes de la información es la estrategia óptima.

Hay dos o tres obstáculos significativos para organizar la información.

1. La falta de percepción de la necesidad de datos-modelo de "normalización".

2. Declaraciones de EF Codd sobre normalización de datos son defectuosos, defectuosos y ambiguos.

3. La última moda que se disfraza de ingeniería ágil es la idea equivocada de que no se debe planificar y condicionar la organización de los módulos por adelantado porque se puede refactorizar sobre la marcha. La refactorización y el cambio continuo sin ser obstaculizado por futuros descubrimientos se utiliza como excusa. Los descubrimientos esenciales del comportamiento de la información de proceso es entonces, mediante el uso de trucos de contabilidad para retrasar los beneficios y la assetization, por lo tanto esencial el conocimiento y su tratamiento no se consideran necesarios ahora.

Usar Constantes de Interfaz es Una Buena Práctica.

No inventes reglas ni emitas ninguna fatwa en su contra solo porque amas tus hábitos de programación ad-hoc de hit-and-run.

No prohibir la posesión de armas con la razón de que hay personas que o bien no saben cómo manejar las armas o son propensos a abusar de las armas.

Si las reglas que inventas están destinadas a los novatos de programación que no pueden codificar profesionalmente y que te consideres entre ellos entonces dilo-no declares tu fatwa como aplicable a modelos de datos correctamente normalizados.

Un razonamiento tonto - Las interfaces no fueron pensadas por los problemas del lenguaje Java para ser utilizadas de esa manera?

No me importa lo que las intenciones originales de los padres fundadores tenían para la Constitución de los Estados Unidos. No me importan las intenciones no escritas y no codificadas. Sólo me importa lo que está literariamente codificado en la Constitución escrita y cómo puede explotarlos para el funcionamiento eficaz de la sociedad.

Solo me importa lo que me permiten las especificaciones del lenguaje/plataforma Java y tengo la intención de explotarlas al máximo para darme un medio para expresar mis soluciones de software de manera eficiente y efectiva. No se requieren chaquetas.

El Uso de Constantes de Enumeración es en realidad una Práctica Horrible.

Requiere escribir código adicional para asignar el parámetro al valor. El hecho de que los fundadores de Java no proporcionaran mapeo parámetro-valor sin su escritura, el código de asignación demuestra que las constantes de Enumeración son el mismo uso involuntario del lenguaje Java.

Especialmente porque no se le anima a normalizar y componentizar sus parámetros, habría una falsa impresión de que los parámetros mezclados en una bolsa de enumeración pertenecen a la misma dimensión.

Las constantes son Contratos API

No lo olvides. Si diseñó y normalizó su modelo de datos, e incluyen constantes,entonces esas constantes son contratos. Si usted no normalizó su modelo de datos, entonces debe ajustarse a las fatwas dadas sobre cómo practicar la codificación restrictiva para hacer frente a ese mal hábito.

Por lo tanto, las interfaces son una forma perfecta de implementar el contrato de Constantes.

Una extraña presunción: ¿Qué pasa si la interfaz se implementa inadvertidamente?

Sí. Cualquiera podría implementar inadvertidamente cualquier interfaz inadvertidamente. Nada se interpondrá en el camino de tales programadores inadvertidos.

Diseño y normalice su modelo de datos contra fugas

No coloque decretos restrictivos para proteger las presuntas malas prácticas que causan la filtración de parámetros no contratados/extraviados en API. Resolver el problema fundamental, en lugar de culpar a las constantes de la interfaz.

No usar un IDE es una mala práctica

Un programador eficaz y de funcionamiento normal no está ahí para demostrar cuánto tiempo puede permanecer bajo el agua, qué tan lejos puede caminar en calor abrasador o tormentas húmedas. Ella es use una herramienta eficiente como un automóvil o un autobús o al menos una bicicleta para llevarla 10 millas al trabajo todos los días.

No impongas restricciones a otros programadores solo porque tengas una obsesión ascética esotérica con la programación sin IDE.

Un par de marcos están diseñados para ayudar a los programadores a seguir practicando malos hábitos de manera eficiente.

OSGI es tal framework. Y también lo es el decreto contra las Constantes de Interfaz.

Por lo tanto, la respuesta concluyente ...

Las constantes de interfaz son una forma efectiva y eficiente de colocar en el Contrato componentes bien diseñados y normalizados de un modelo de datos.

Las constantes de interfaz en una interfaz privada apropiadamente llamada anidada en un archivo de clase también son una buena práctica para agrupar todas sus constantes privadas en lugar de dispersarlas por todo el archivo.

Son útiles si tiene constantes comunes que se utilizarán en clases que implementan la interfaz.

Aquí hay un ejemplo: http://www.javapractices.com/topic/TopicAction.do?Id=32

Pero tenga en cuenta que la práctica recomendada es utilizar importaciones estáticas en lugar de constantes en las interfaces. Aquí hay una referencia: http://www.javapractices.com/topic/TopicAction.do?Id=195

Uso constantes de interfaz cuando se trata de constantes compartidas entre clases.

public interface TestConstants
{
    String RootLevelConstant1 = "RootLevelConstant1";

    interface SubGroup1
    {
        String SubGroupConstant1 = "SubGroup1Constant1";
        String SubGroupConstant2 = "SubGroup1Constant2";
    }

    interface SubGroup2
    {
        String SubGroupConstant1 = "SubGroup2Constant1";
        String SubGroupConstant2 = "SubGroup2Constant2";
    }
}

La agrupación es un activo enorme, especialmente con un gran conjunto de constantes.

Para usar, simplemente los encadenas:

System.out.println(TestConstants.SubGroup1.SubGroupConstant1);
System.out.println(TestConstants.SubGroup2.SubGroupConstant1);
System.out.println(TestConstants.RootLevelConstant1);

Hay respuestas que son muy razonables.

Pero tengo algunas ideas sobre esta pregunta. (puede estar mal)

En mi opinión, los campos en una interfaz, no deben ser constantes a todo el proyecto, solo son medios para la interfaz y las interfaces la extienden y las clases que son implementan estas interfaces o tienen una relación cercana con ellas. Deben utilizarse dentro de un cierto rango no global.

El javax.swing.SwingConstants interface es un ejemplo que tiene campos estáticos que se utilizan entre las clases swing. Esto le permite utilizar fácilmente algo como

• this.add(LINE_START, swingcomponent);
• this.add(this.LINE_START, swingcomponent); o
• this.add(SwingComponents.LINE_START, swingcomponent);

Sin embargo, esta interfaz no tiene métodos...

Me encontré con esta pregunta y pensé en agregar algo que no se mencionó. En general, estoy de acuerdo con la respuesta de Pascal aquí. Sin embargo, no creo que las constantes en una interfaz sean "siempre" un antipatrón.

Por ejemplo, si las constantes que está definiendo son parte de un contrato para esa interfaz, creo que la interfaz es un gran lugar para las constantes. En algunos casos, simplemente no es apropiado validar de forma privada sus parámetros sin exponer el contrato a los usuarios de su implementación. Sin un contrato público, los usuarios solo pueden adivinar con qué validas, sin descompilar la clase y leer tu código.

Por lo tanto, si implementa una interfaz y la interfaz tiene las constantes que utiliza para garantizar sus contratos (como rangos de enteros, por ejemplo), entonces un usuario de su clase puede estar seguro de que está utilizando la instancia de interfaz correctamente comprobando las constantes en la interfaz. Esto sería imposible si las constantes fueran privadas para su implementación o su implementación era un paquete privado o algo así.

Me encontré con esta vieja pregunta varias veces ahora y la respuesta aceptada todavía me confunde. Después de pensar mucho, creo que esta pregunta puede aclararse aún más.

¿En qué caso es una mala práctica?

Creo que la respuesta de @Pascal Thivent tiene el énfasis equivocado, aquí está mi versión de ella:

Poner miembros estáticos en una interfaz ( e implementar esa interfaz) es una mala práctica.

La cita de Effective Java tiene la suposición de que la interfaz constante está siendo implementada por otros, lo que creo que no debería (y no sucederá) suceder.

Cuando creas una interfaz constante llamada algo así como Constants, ¿quién en el mundo la implementará? (aunque técnicamente posible, que es el único problema)

No sucederá en la biblioteca estándar

La biblioteca estándar no puede permitirse ningún posible mal uso del diseño, por lo que simplemente no verá ninguno allí.

Sin embargo , para diario proyectos de desarrolladores normales, el uso de la interfaz de constantes es mucho más fácil porque no necesita preocuparse static, final, empty constructor, etc, y no causará ningún problema de diseño malo. El único inconveniente que se me ocurre es que todavía tiene el nombre de "interfaz", pero nada más que eso.

Los campos deben declararse en una interfaz para que sean más fáciles de compartir y se puede hacer referencia sin introducir acoplamiento adicional.

Fuente: Java Herramientas del desarrollador Estilo de codificación