¿El diseño por contrato funciona para usted?[cerrado]

Question

¿Utilizas Diseño por Contrato profesionalmente?¿Es algo que tienes que hacer desde el principio de un proyecto, o puedes cambiar de rumbo y empezar a incorporarlo en tu ciclo de vida de desarrollo de software?¿Cuáles ha encontrado que son los pros y los contras del enfoque de diseño?

me encontré con el Diseño por contrato enfoque en un curso de posgrado.En el ámbito académico, parecía ser una técnica bastante útil.Pero actualmente no uso Design by Contract de manera profesional y no conozco a ningún otro desarrollador que lo esté usando.Sería bueno conocer su uso real por parte de la multitud de SO.

Answer 1

No puedo recomendarlo lo suficiente.Es particularmente bueno si tiene una suite que toma especificaciones de contrato de documentación en línea, como esta:

// @returns null iff x = 0
public foo(int x) {
  ...
}

y los convierte en pruebas unitarias generadas, así:

public test_foo_returns_null_iff_x_equals_0() {
  assertNull foo(0);
}

De esa manera, puedes ver las pruebas que estás ejecutando, pero se generan automáticamente.Por cierto, las pruebas generadas no deben incluirse en el control de fuente.

Answer 2

Realmente puedes apreciar el diseño por contrato cuando tienes una interfaz entre aplicaciones que tienen que comunicarse entre sí.

Sin contratos, esta situación rápidamente se convierte en un juego de tenis de culpas.Los equipos siguen lanzando acusaciones de un lado a otro y se pierden enormes cantidades de tiempo.

Con contrato, la culpa es clara.

¿La persona que llama cumplió las condiciones previas?De lo contrario, el equipo del cliente debe solucionarlo.

Dada una solicitud válida, ¿cumplió el destinatario las condiciones del puesto?De lo contrario, el equipo del servidor debe solucionarlo.

¿Ambas partes cumplieron el contrato, pero el resultado no es satisfactorio?El contrato es insuficiente y es necesario escalar el asunto.

Para ello no es necesario que los contratos se implementen en forma de afirmaciones, sólo hay que asegurarse de que estén documentados y acordados por todas las partes.

Answer 3

Si observa STL, boost, MFC, ATL y muchos proyectos de código abierto, puede ver que hay tantas declaraciones ASSERTION y eso hace que el proyecto avance de manera más segura.

¡Diseño por contrato!Realmente funciona en un producto real.

Answer 4

Frank Krueger escribe:

Cayo:El tiempo de ejecución genera automáticamente una excepción de puntero nulo; no hay ningún beneficio en probar esas cosas en el prólogo de la función.

Tengo dos respuestas a esto:

1. Nulo fue sólo un ejemplo.Para cuadrado (x), me gustaría probar que la raíz cuadrada del resultado es (aproximadamente) el valor del parámetro.Para los configuradores, me gustaría probar que el valor realmente cambió.Para operaciones atómicas, me gustaría verificar que todas las operaciones de los componentes tuvieron éxito o todas fallaron (en realidad, una prueba de éxito y n pruebas de falla).Para los métodos de fábrica en lenguajes de tipo débil, quiero verificar que se devuelva el tipo correcto de objeto.La lista sigue y sigue.Básicamente, cualquier cosa que pueda probarse en una línea de código es un muy buen candidato para un contrato de código en un comentario de prólogo.

2. No estoy de acuerdo con que no debas probar cosas porque generan excepciones de tiempo de ejecución.En todo caso, usted debería Pruebe cosas que puedan generar excepciones en tiempo de ejecución.Me gustan las excepciones de tiempo de ejecución porque hacen que el sistema Fallar rapido, lo que ayuda a la depuración.Pero el null en el ejemplo había un valor de resultado para alguna posible entrada.Hay un argumento para no regresar nunca null, pero si vas a hacerlo, deberías probarlo.

Answer 5

Es absolutamente tonto no diseñar por contrato cuando se hace algo en un ámbito SOA, y siempre es útil si estás trabajando en cualquier tipo de trabajo modular, donde partes y piezas podrían intercambiarse más adelante, especialmente si hay cajas negras involucradas. .

Answer 6

En lugar de sistemas de tipos más expresivos, absolutamente usaría el diseño por contrato en proyectos de grado militar.

Para lenguajes débilmente tipados o lenguajes con alcance dinámico (PHP, JavaScript), los contratos funcionales también son muy útiles.

Para todo lo demás, lo dejaría de lado y confiaría en los probadores beta y las pruebas unitarias.

Cayo:El tiempo de ejecución genera automáticamente una excepción de puntero nulo; no hay ningún beneficio en probar esas cosas en el prólogo de la función.Si está más interesado en la documentación, entonces usaría anotaciones que se pueden usar con analizadores estáticos y similares (para asegurarme de que el código no rompa sus anotaciones, por ejemplo).

Un sistema de tipos más sólido junto con el Diseño por contrato parece ser el camino a seguir.Echa un vistazo a Especificaciones# para un ejemplo:

El lenguaje de programación Spec#.La especificación# es una extensión del lenguaje orientado a objetos C#.Extiende el sistema de tipos para incluir tipos no nulos y excepciones verificadas.Proporciona contratos de métodos en forma de pre y y postesdiciones, así como invariantes de objetos.

Answer 7

Tanto las pruebas unitarias como el diseño por contrato son enfoques de prueba valiosos en mi experiencia.

Intenté usar Diseño por contrato en un marco de prueba automática del sistema y mi experiencia es que brinda flexibilidad y posibilidades que no se obtienen fácilmente mediante pruebas unitarias.Por ejemplo, es posible ejecutar una secuencia más larga y verificar que los tiempos de respuesta estén dentro de los límites cada vez que se ejecuta una acción.

Al observar las presentaciones en InfoQ, parece que el diseño por contrato es una valiosa adición a las pruebas unitarias convencionales en la fase de integración de componentes.Por ejemplo, es posible crear una interfaz simulada primero y luego usar el componente después, o cuando se libera una nueva versión de un componente.

No he encontrado un kit de herramientas que cubra todos mis requisitos de diseño para diseñar mediante pruebas de contrato en la plataforma .NET/Microsoft.

Answer 8

En realidad, no uso Diseño por contrato a diario.Sin embargo, sé que se ha incorporado al D lengua, como parte de la lengua.

Answer 9

¡Sí, lo hace!De hecho, hace unos años, diseñé un pequeño marco para la validación de argumentos.Estaba haciendo un proyecto SOA, en el que los diferentes sistemas de back-end hacían todo tipo de validación y verificación.Pero para aumentar los tiempos de respuesta (en los casos en que la entrada no era válida y reducir la carga de esos sistemas back-end), comenzamos a validar los parámetros de entrada de los servicios proporcionados.No sólo para Not Null, sino también para patrones String.O valores dentro de conjuntos.Y también los casos en los que los parámetros tenían dependencias entre ellos.

Ahora me doy cuenta de que implementamos en ese momento un pequeño marco de diseño por contrato :)

Aquí está el enlace para aquellos que estén interesados ​​en el pequeño. Validación de argumentos de Java estructura.Que se implementa como una solución Java simple.

Answer 10

Me parece revelador que el lenguaje de programación Go no tenga construcciones que hagan posible el diseño por contrato.pánico/aplazamiento/recuperación no son exactamente eso, ya que la lógica de aplazar y recuperar permite ignorar el pánico, y OIA ignorar el contrato roto.Lo que se necesita al menos es alguna forma de pánico irrecuperable, lo que realmente se afirma.O, en el mejor de los casos, soporte lingüístico directo del diseño mediante construcciones contractuales (condiciones previas y posteriores, implementación e invariantes de clase).Pero dada la terquedad de los puristas del lenguaje al mando de Go, doy pocos cambios de todo lo que se ha hecho.

Se puede implementar un comportamiento similar a una afirmación comprobando si hay un error de afirmación especial en la última función de aplazamiento en la función de pánico y llamando a runtime.Breakpoint() para volcar la pila durante la recuperación.Para ser asertivo, ese comportamiento debe ser condicional.Por supuesto, este enfoque se desmorona cuando se agrega una nueva función de aplazamiento después de la que hace afirmar.Lo que sucederá en un proyecto grande exactamente en el momento equivocado, lo que provocará la omisión de errores.

Lo que quiero decir es que afirmar es útil de tantas maneras que tener que darle vueltas puede ser un dolor de cabeza.