Adición de invariantes a interfaces en Java

He estado pensando en crear un marco de trabajo Java que permita a los programadores especificar invariantes (condiciones previas y posteriores) en las interfaces. El objetivo sería hacer que el código sea más robusto y reducir el número de pruebas unitarias que deberían escribirse para diferentes implementaciones de la misma interfaz.Adición de invariantes a interfaces en Java

Imagino crear alguna manera de anotar métodos con invariantes que el programador también escribiría. P.EJ.

interface Sort { 
    int [] sort(int [] nums); 
}

sería adornado con una anotación para asegurar que cualquier implementación devuelven una lista ordenada. Esta anotación estaría vinculada a una prueba unitaria que podría ejecutarse en tiempo de compilación contra cualquier implementación.

¿Es esta una idea loca o sería útil para una comunidad de programación más amplia?

Fuente

2010-07-22 Tarski

No estoy seguro de si vincularlo con la prueba de unidad es una buena jugada durante el tiempo de compilación. Porque "pasar la prueba es solo algo", si sabes a qué me refiero. Usar un tejedor de aspecto puede ser un mejor enfoque, ¿no? (Entonces la siguiente pregunta será - rendimiento) – yclian

@yclian, creo que la idea era usar estas condiciones previas y posteriores para realizar varios análisis estáticos a fin de reducir el número de pruebas unitarias que tendrían que escribirse en orden para obtener cobertura equivalente No vi ninguna implicación de que esto necesariamente sea una cosa de tiempo de ejecución (aunque tal vez algunas afirmaciones de tiempo de ejecución podrían utilizarse para proteger las declaraciones de que el análisis estático no podría ser seguro). – Gian

Parece que podría estar relacionado con JML y ESC/Java, los cuales han encontrado una adopción bastante amplia dentro de los tipos de proyectos que necesitan un poco más de calidad de software que la ofrecida por el conjunto habitual de técnicas.

Fuente

2010-07-22 15:29:53 Gian

Gracias, voy a echar un vistazo a JML – Tarski

que nunca he oído hablar de ninguno. "Adopción razonablemente extendida": datos, por favor. Apuesto a que no tiene ningún fundamento para esta afirmación, a excepción de uno o dos proyectos que ha realizado. – duffymo

@duffymo, no creo que el tono agresivo sea necesario. Califiqué "adopción razonablemente extendida". Estaba basando la afirmación en el hecho de que se enseña en al menos algunas universidades que yo sepa, existe un ecosistema bastante saludable de herramientas JML (http://en.wikipedia.org/wiki/Java_Modeling_Language#Tool_Support), y la mayoría de los ingenieros profesionales probablemente estén al menos familiarizados con JML como concepto. También hay un buen número de publicaciones revisadas por pares que tratan sobre JML (http://scholar.google.com/scholar?hl=es&q=java+modeling+language). – Gian

¡Qué gran idea de programación no es una locura! Definitivamente creo que sería útil.

Fuente

2010-07-22 15:31:38

De acuerdo, pero ¿no debería ser este un comentario? – whiskeysierra

Creo que la programación de Bertrand Meyer por contrato está prácticamente muerta. Construyó condiciones previas y posteriores en Eiffel, pero ese idioma está por debajo del latín en la escala de uso.

Hay programación de Java por bibliotecas contractuales; Contractor es uno. Pero su día ha llegado y se ha ido. El hecho es que incluso Eiffel tenía una forma de desactivarlos en producción, porque el costo del tiempo de ejecución no valía la pena.

Solo 6 preguntas de Eiffel sobre desbordamiento de pila: un pequeño porcentaje de hecho. Si busca etiquetas SO con "contrato" en ellas, verá un número muy pequeño. No hay mucho interés en el tema en este sitio. Afirma atraer a la audiencia más grande de programadores profesionales en el mundo.

Fuente

2010-07-22 20:10:38 duffymo

vistas interesantes. ¿diría usted que el desarrollo impulsado por pruebas es un mejor enfoque que el diseño por contrato? – Tarski

"¿Diría que el desarrollo basado en pruebas es un mejor enfoque que el diseño por contrato?" - Absolutamente. No hay penalización de tiempo de ejecución; proporcionan mejor información sobre el comportamiento de las clases; documentan mucho mejor de lo que lo harían los contratos. Si tuviera una opción, preferiría tener las pruebas. – duffymo

No diría que documentan mucho mejor de lo que lo harían los contratos. Usando TDD, puede probar algunas entradas para estirar la funcionalidad, pero un contacto puede definir en términos abstractos lo que realmente hace la función. p.ej. una función suma (x, y) podría tener devoluciones de contrato x + y, mientras que una prueba podría simplemente afirmar esa suma (1, 2) = 3 – Tarski

Creo que el diseño por contrato es una gran idea y he echado un vistazo a los marcos que proporcionan esa funcionalidad en Java. Creo que lo que me ha frenado es que conseguir el apoyo de un equipo para este tipo de marcos puede ser difícil. Creo que se percibe como de interés académico lo que es extraño porque realmente es como incrustar pruebas unitarias dentro del código.

El principal asentimiento de Java en esta dirección, la declaración de afirmación, ha existido durante varios años, pero rara vez lo veo usado, ¡a menudo solo en el código que escribo! Hay mucho kilometraje en el uso de afirmaciones (especialmente combinado con pruebas unitarias) y he encontrado algunos errores usándolos, es una pena que la gente no los use.

Cheers,

Ian.

Fuente

2010-07-23 13:44:15

Estoy de acuerdo con usted que las afirmaciones están infrautilizadas. Acabo de hacer mi examen SCJP y Sun recomienda usar aseveraciones para verificar condiciones previas solo en métodos privados. Pero en realidad, no hay nada que le impida usarlos para verificar las condiciones posteriores también. El problema que tengo con las aserciones es que están deshabilitadas de manera predeterminada. Me gustaría utilizar un marco que compile la verificación del tiempo. – Tarski

Adición de invariantes a interfaces en Java

Respuesta

Cuestiones relacionadas