Potrebbe progettare per contratto (DbC) essere un modo di programmare in modo difensivo?
È un modo di programmare meglio in alcuni casi rispetto all'altro?
Potrebbe progettare per contratto (DbC) essere un modo di programmare in modo difensivo?
È un modo di programmare meglio in alcuni casi rispetto all'altro?
Design by Contract e programmazione difensiva sono in un certo senso opposti l'uno dell'altro: in DbC, si definiscono i contratti tra i collaboratori e si programma in base al presupposto che i collaboratori onorino i loro contratti. Nella programmazione difensiva, programmi in base al presupposto che i tuoi collaboratori violano i loro contratti.
Una vera e propria routine di radice quadrata scritta in stile DbC affermerebbe nel suo contratto che non ti è permesso passare un numero negativo e quindi semplicemente supponi che non possa mai incontrare un numero negativo. Una vera e propria routine di radice quadrata scritta in modo difensivo assumerebbe che sia passato un numero negativo e prendere le precauzioni appropriate.
Nota: è ovviamente possibile che in DbC qualcun altro verifichi il contratto. Ad esempio, ad Eiffel, il sistema contrattuale controllerebbe un numero negativo in fase di esecuzione e genererebbe un'eccezione appropriata. In Spec #, il proverbio del teorema controllerebbe i numeri negativi al momento della compilazione e fallirebbe la compilazione, se non può dimostrare che la routine non riceverà mai un numero negativo. La differenza è che il programmatore non effettua questo controllo.
Could Designing by Contract (DbC) be a way to program defensively?
Sì.
"Programmazione difensiva" è spesso una scusa per perdere tempo. Spesso si perde tempo a controllare le cose che causano eccezioni ordinarie. Invece delle eccezioni, vengono scritte istruzioni IF extra invece delle clausole di gestione delle eccezioni.
Definisci il contratto e fallo con esso.
Quando qualcuno viola il contratto, il programma, nel corso normale degli eventi, interromperà e solleverà le normali eccezioni che possono essere normalmente gestite.
"Programmazione difensiva" e "Prevenzione degli errori" possono essere visualizzati per aggiungere errori (perché i controlli di prevenzione degli errori sono essi stessi errati) piuttosto che evitare errori.
La gestione delle eccezioni può mettere a tacere, registrare e gestire un'eccezione molto meglio di "Programmazione difensiva".
Leggi altre domande sui tag design-patterns defensive-programming contract