Différences entre la conception par contrat et la programmation défensive

La conception par contrat (DbC) pourrait-elle être un moyen de programmer de manière défensive?

Une façon de programmer est-elle meilleure dans certains cas que l'autre?

design-patterns contract defensive-programming

— Gabriel Fair
source

La conception par contrat et la programmation défensive sont en quelque sorte opposées: dans DbC, vous définissez des contrats entre collaborateurs et vous programmez en supposant que les collaborateurs respectent leurs contrats. En programmation défensive, vous programmez en supposant que vos collaborateurs violent leurs contrats.

Une véritable routine de racine carrée écrite dans le style DbC indiquerait dans son contrat que vous n'êtes pas autorisé à passer un nombre négatif, puis supposerait simplement qu'elle ne peut jamais rencontrer un nombre négatif. Une vraie routine de racine carrée écrite de manière défensive supposerait qu'elle passe un nombre négatif et prendrait les précautions appropriées.

Remarque: il est bien sûr possible qu'en DbC quelqu'un d'autre vérifie le contrat. Dans Eiffel, par exemple, le système de contrat vérifierait un nombre négatif lors de l'exécution et lèverait une exception appropriée. Dans Spec #, le prouveur de théorèmes vérifierait les nombres négatifs au moment de la compilation et échouerait à la construction, s'il ne pouvait pas prouver que la routine ne passerait jamais un nombre négatif. La différence est que le programmeur n'effectue pas cette vérification.

— Jörg W Mittag
source

La conception par contrat (DbC) pourrait-elle être un moyen de programmer de manière défensive?

Oui.

La «programmation défensive» est souvent une excuse pour perdre du temps. Cela gaspille souvent du temps à vérifier les choses qui provoqueront des exceptions ordinaires. Au lieu des exceptions, des instructions IF supplémentaires sont écrites à la place des clauses de gestion des exceptions.

Définissez le contrat et terminez-le.

Lorsque quelqu'un viole le contrat, le programme - dans le cours normal des événements - casse et soulève des exceptions normales qui peuvent être normalement gérées.

La "programmation défensive" et la "prévention des erreurs" peuvent s'afficher pour ajouter des erreurs (car les contrôles de prévention des erreurs sont eux-mêmes erronés) plutôt que pour empêcher les erreurs.

La gestion des exceptions peut réduire au silence, enregistrer et gérer une exception bien mieux que la «programmation défensive».

— S.Lott
source

La programmation défensive est moe que juste si des déclarations. Il comprend des revues de code, des analyses statiques, des audits de sécurité, des directives de codage sécurisé, et plus encore. De plus, l'utilisation d'exceptions et la gestion des exceptions (au lieu de simplement laisser le programme planter et graver) est considérée comme une technique de programmation défensive.

— Thomas Owens

@ThomasOwens: Cela ressemble à un "bon développement logiciel". Je n'ai jamais vu de programmation défensive utilisée comme excuse pour écrire de nombreuses instructions IF (ou assertions) qui échouent avant que des exceptions ne soient normalement levées. Je n'appellerais pas votre longue liste de très bonnes idées "programmation défensive". J'appellerais votre liste de bonnes idées "Programmation". De cette façon, nous pouvons séparer la perte de temps de toutes les choses intelligentes que vous listez.

— S.Lott

Je préfère appeler moi-même ces "bonnes idées lors de l'écriture de code", mais quand on m'a enseigné la programmation défensive, on m'a appris qu'elle faisait référence à toutes les techniques dans le but exprès d'assurer la sûreté, la sécurité et la fiabilité d'un système. . C'est peut-être une définition trop large, ou peut-être que c'est une mauvaise définition, mais c'est ce qu'on m'a appris. J'ai vu des gens appeler si des déclarations et des assertions "programmation défensive", mais d'après la définition qui m'a été enseignée, je ne l'appellerais pas ainsi (sauf dans les cas où vous n'avez pas nécessairement de meilleures options, comme les exceptions).

— Thomas Owens

@ThomasOwens: "Peut-être que c'est une définition trop large". Se mettre d'accord. Cela semble être une excellente liste de contrôle de bonnes idées.

— S.Lott

-1: Je ne vois pas comment DbC est un moyen de programmer défensivement, ils sont fondamentalement opposés. Je doute qu'il soit courant de faire une programmation défensive juste pour perdre du temps. Et «on peut montrer qu'il peut ajouter des erreurs» a besoin d'une citation car ce n'est pas du tout évident.

— Mark