Diferenças entre projeto por contrato e programação defensiva

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-patterns contract defensive-programming

— Gabriel Fair
fonte

Respostas:

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.

— Jörg W Mittag
fonte

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".

— S.Lott
fonte

A programação defensiva é mais do que apenas declarações if. Inclui análises de código, análise estática, auditorias de segurança, diretrizes de codificação segura e muito mais. Além disso, o uso de exceções e o tratamento de exceções (em vez de simplesmente deixar o programa travar e gravar) é considerado uma técnica de programação defensiva.

— Thomas Owens

@ ThomasOwens: Isso soa como "Bom desenvolvimento de software". Eu só vi a programação defensiva usada como uma desculpa para escrever muitas instruções IF (ou asserções) que falham antes que as exceções sejam normalmente levantadas. Eu não chamaria sua longa lista de boas idéias de "Programação Defensiva". Eu chamaria sua lista de boas idéias de "Programação". Dessa forma, podemos separar a perda de tempo de todas as coisas inteligentes que você lista.

— S.Lott

Prefiro chamar essas "boas idéias ao escrever código", mas quando fui ensinado sobre programação defensiva, aprendi que ele se referia a toda e qualquer técnica com o objetivo expresso de garantir a segurança, a proteção e a confiabilidade de um sistema . Talvez essa seja uma definição muito ampla, ou talvez seja uma definição errada, mas foi o que me ensinaram. Eu já vi pessoas chamarem as declarações e afirmações de "programação defensiva", mas com base na definição que me foi ensinada, não a chamaria assim (exceto nos casos em que você não necessariamente tem melhores opções, como exceções).

— Thomas Owens

@ThomasOwens: "Talvez seja uma definição muito ampla". Aceita. Parece uma ótima lista de boas idéias.

— S.Lott

-1: Não vejo como o DbC é uma maneira de programar defensivamente, eles são basicamente opostos. Duvido que seja comum fazer programação defensiva apenas para perder tempo. E 'pode ser mostrado para adicionar erros' precisa de uma citação, porque não é de todo óbvio.

— Mark