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?
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.
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».