¿Podría Designing by Contract (DbC) ser una forma de programar a la defensiva?
¿Es una forma de programar mejor en algunos casos que la otra?
¿Podría Designing by Contract (DbC) ser una forma de programar a la defensiva?
¿Es una forma de programar mejor en algunos casos que la otra?
Respuestas:
El diseño por contrato y la programación defensiva son, en cierto sentido, opuestos entre sí: en DbC, usted define contratos entre colaboradores y programa bajo el supuesto de que los colaboradores cumplen sus contratos. En la programación defensiva, usted programa bajo el supuesto de que sus colaboradores violan sus contratos.
Una rutina de raíz cuadrada real escrita en estilo DbC indicaría en su contrato que no se le permite pasar un número negativo y luego simplemente supondrá que nunca puede encontrar un número negativo. Una rutina de raíz cuadrada real escrita a la defensiva supondría que se pasa un número negativo y tomaría las precauciones adecuadas.
Nota: por supuesto, es posible que en DbC alguien más verifique el contrato. En Eiffel, por ejemplo, el sistema de contrato verificaría un número negativo en tiempo de ejecución y lanzaría una excepción apropiada. En Spec #, el probador de teoremas verificaría los números negativos en el momento de la compilación y fallaría la compilación, si no puede probar que la rutina nunca pasará un número negativo. La diferencia es que el programador no hace esta verificación.
¿Podría Designing by Contract (DbC) ser una forma de programar a la defensiva?
Sí.
La "programación defensiva" suele ser una excusa para perder el tiempo. A menudo se pierde el tiempo buscando cosas que causen excepciones comunes. En lugar de las excepciones, se escriben declaraciones IF adicionales en lugar de cláusulas de manejo de excepciones.
Defina el contrato y termine con él.
Cuando alguien viola el contrato, el programa, en el curso normal de los eventos, romperá y generará excepciones normales que normalmente se pueden manejar.
Se puede mostrar que la "programación defensiva" y la "prevención de errores" agregan errores (porque las comprobaciones de prevención de errores son erróneas) en lugar de evitar errores.
El manejo de excepciones puede silenciar, registrar y manejar una excepción mucho mejor que la "Programación Defensiva".