O Design by Contract (DbC) poderia ser uma maneira de programar defensivamente?
Em alguns casos, uma maneira de programar é melhor do que a outra?
fonte
O Design by Contract (DbC) poderia ser uma maneira de programar defensivamente?
Em alguns casos, uma maneira de programar é melhor do que a outra?
Design por contrato e programação defensiva são, em certo sentido, opostos um do outro: no DbC, você define contratos entre colaboradores e programa sob a premissa de que os colaboradores honram seus contratos. Na programação defensiva, você programa sob a premissa de que seus colaboradores violam seus contratos.
Uma rotina de raiz quadrada real escrita no estilo DbC declararia em seu contrato que você não tem permissão para transmitir um número negativo e, em seguida, simplesmente presumir que nunca poderá encontrar um número negativo. Uma rotina de raiz quadrada real, escrita defensivamente, pressupõe que seja passado um número negativo e toma as precauções apropriadas.
Nota: é claro que é possível que em DbC alguém verifique o contrato. Em Eiffel, por exemplo, o sistema contratado verificaria um número negativo em tempo de execução e lançaria uma exceção apropriada. No Spec #, o provador do teorema procuraria números negativos no momento da compilação e falharia na compilação, se não puder provar que a rotina nunca terá passado um número negativo. A diferença é que o programador não faz essa verificação.
O Design by Contract (DbC) poderia ser uma maneira de programar defensivamente?
Sim.
"Programação defensiva" é frequentemente uma desculpa para perder tempo. Muitas vezes, perde tempo verificando coisas que causam exceções comuns. Em vez das exceções, instruções IF adicionais são gravadas em vez de cláusulas de tratamento de exceções.
Defina o contrato e termine com ele.
Quando alguém viola o contrato, o programa - no curso normal dos eventos - quebra e gera exceções normais que podem ser tratadas normalmente.
"Programação defensiva" e "Prevenção de erros" podem ser mostradas para adicionar erros (porque as próprias verificações de prevenção de erros são errôneas) em vez de evitar erros.
O tratamento de exceções pode silenciar, registrar e manipular uma exceção muito melhor que a "Programação defensiva".