J'ai récemment découvert Design by Contract (DbC) et je trouve que c'est un moyen extrêmement intéressant d'écrire du code. Entre autres choses, il semblerait offrir:
- Meilleure documentation. Étant donné que le contrat est la documentation, il est impossible qu’une personne soit périmée. De plus, comme le contrat spécifie exactement ce que fait une routine, il facilite la réutilisation.
- Débogage plus simple. Étant donné que l'exécution du programme s'arrête en cas d'échec d'un contrat, les erreurs ne peuvent pas se propager et l'assertion spécifique violée sera probablement mise en évidence. Ceci offre un support lors du développement et de la maintenance.
- Meilleure analyse statique. DbC est fondamentalement juste une implémentation de la logique de Hoare, et les mêmes principes devraient s'appliquer.
Les coûts, en comparaison, semblent plutôt minimes:
- Dactylographie supplémentaire. Depuis les contrats doivent être précisés.
- Prend un peu de formation pour se familiariser avec la rédaction de contrats.
Maintenant, connaissant principalement Python, je me rends compte qu’il est en fait possible d’écrire des conditions préalables (en lançant juste des exceptions pour des entrées inappropriées) et qu’il est même possible d’utiliser des assertions pour tester à nouveau certaines post-conditions. Mais il n'est pas possible de simuler certaines fonctionnalités telles que "ancien" ou "résultat" sans une magie supplémentaire qui serait finalement considérée comme non pythonique. (En outre, quelques bibliothèques offrent un support, mais au final, j'ai l'impression qu'il serait erroné de les utiliser, contrairement à la plupart des développeurs.) Je suppose que c'est un problème similaire pour tous les autres langages (sauf bien sûr , Eiffel).
Mon intuition me dit que le manque de soutien doit être le résultat d’une sorte de rejet de la pratique, mais la recherche en ligne n’a pas été fructueuse. Je me demande si quelqu'un peut expliquer pourquoi la plupart des langues modernes semblent offrir si peu d'assistance? DbC est-il défectueux ou trop cher? Ou est-ce simplement obsolète en raison de la programmation extrême et d'autres méthodologies?
la source
Réponses:
On peut soutenir qu'ils sont pris en charge dans pratiquement tous les langages de programmation.
Ce dont vous avez besoin, ce sont des "assertions".
Celles-ci sont facilement codées comme "if":
Avec cela, vous pouvez rédiger des contrats en plaçant ces assertions en haut de votre code pour les contraintes d'entrée; ceux aux points de retour sont des contraintes de sortie. Vous pouvez même ajouter des invariants dans votre code (bien que cela ne fasse pas vraiment partie de la "conception par contrat").
Donc, je soutiens qu'ils ne sont pas répandus parce que les programmeurs sont trop paresseux pour les coder, pas parce que vous ne pouvez pas le faire.
Vous pouvez les rendre un peu plus efficaces dans la plupart des langues en définissant une "vérification" de constante booléenne au moment de la compilation et en révisant un peu les instructions:
Si vous n'aimez pas la syntaxe, vous pouvez recourir à diverses techniques d'abstraction de langage telles que les macros.
Certaines langues modernes vous offrent une syntaxe intéressante, et c'est ce que vous entendez par "support des langues modernes". C'est un soutien, mais c'est assez mince.
Ce que la plupart des langues modernes ne vous donnent pas, ce sont des assertions "temporelles" (sur des états arbitraires antérieurs ou suivants [opérateur temporel "éventuellement"], dont vous avez besoin si vous voulez rédiger des contrats très intéressants. Les instructions IF ne vous aideront pas vous ici.
la source
superméthode complète et éventuellement jeter les résultats si vous souhaitez uniquement vérifier les contrats sans les dupliquer. Cela aide vraiment à implémenter du code propre et conforme au LSP.Comme vous le dites, Design by Contract est une fonctionnalité d’Eiffel, qui est depuis longtemps l’un de ces langages de programmation très respectés dans la communauté mais qui n’a jamais fait son chemin.
DbC n'est pas dans les langages les plus populaires car ce n'est que récemment que la communauté de la programmation traditionnelle a fini par accepter que l'ajout de contraintes / attentes à leur code était une chose "raisonnable" à attendre des programmeurs. Il est maintenant courant pour les programmeurs de comprendre à quel point les tests unitaires sont précieux, et cela a beaucoup plu aux programmeurs qui acceptaient mieux de mettre du code pour valider leurs arguments et de voir les avantages. Mais il y a dix ans, la plupart des programmeurs diraient probablement que "ce n'est que du travail supplémentaire pour des choses que vous savez, ça va toujours aller".
Je pense que si vous vous adressiez au développeur moyen aujourd'hui et que vous parlez de post-conditions, il inclinerait la tête avec enthousiasme et dirait "OK, c'est comme des tests unitaires". Et si vous parlez de conditions préalables, ils diraient "OK, c'est comme la validation de paramètre, ce que nous ne faisons pas toujours, mais, vous savez, je suppose que ça va ..." Et ensuite, si vous parlez d'invariants , ils commençaient à dire: "Gee, combien de temps cela représente? Combien de bugs allons-nous attraper?" etc.
Je pense donc qu’il reste encore beaucoup à faire avant que DbC soit très largement adopté.
la source
Faux.
C'est une pratique de conception . Il peut être incorporé explicitement dans le code (style Eiffel) ou implicitement dans le code (la plupart des langues) ou dans des tests unitaires. La pratique du design existe et fonctionne bien. Le support linguistique est partout sur la carte. Il est toutefois présent dans de nombreuses langues dans la structure de test unitaire.
C'est cher. Et. Plus important encore, certaines choses ne peuvent pas être prouvées dans une langue donnée. La terminaison de boucle, par exemple, ne peut pas être prouvée dans un langage de programmation, elle nécessite une capacité de preuve "d'ordre supérieur". Certains types de contrats sont donc techniquement inexprimables.
Non.
Nous utilisons principalement des tests unitaires pour démontrer que DbC est remplie.
Comme vous l'avez noté, pour Python, le DBC est utilisé à plusieurs endroits.
Les résultats du test docstring et docstring.
Assertions pour valider les entrées et les sorties.
Tests unitaires.
Plus loin.
Vous pouvez adopter des outils de style de programmation alphabétisés afin de rédiger un document contenant vos informations DbC et générant des scripts de test d'unité propres Python. L'approche de programmation alphabète vous permet d'écrire une belle littérature qui inclut les contrats et la source complète.
la source
there are some things which cannot be proven. La vérification formelle peut être formidable, mais tout n’est pas vérifiable! Donc, cette fonctionnalité limite réellement ce que le langage de programmation peut réellement faire!Juste deviner. Une des raisons pour lesquelles il n'est pas si populaire est parce que "Design by Contract" est une marque déposée par Eiffel.
la source
Une hypothèse est que, pour un programme complexe suffisamment volumineux, en particulier pour les cibles mobiles, la masse des contrats eux-mêmes peut devenir aussi complexe et difficile à déboguer que le code du programme seul. Comme avec tout modèle, il peut y avoir une utilisation passée des rendements décroissants, ainsi que des avantages évidents lorsqu'elle est utilisée de manière plus ciblée.
Une autre conclusion possible est que la popularité des "langues gérées" est la preuve actuelle de la prise en charge, conception par contrat, des fonctionnalités gérées sélectionnées (bornes de tableau par contrat, etc.).
la source
La raison pour laquelle la plupart des langages traditionnels n'ont pas de fonctionnalités DbC dans le langage est le rapport coût / bénéfice de sa mise en œuvre est trop élevé pour le développeur de langage.
une partie de cela a déjà été examinée dans les autres réponses, des tests unitaires et d'autres mécanismes d'exécution (ou même des mécanismes de compilation avec méta-programmation) peuvent vous donner déjà une bonne part de la bonté de DbC. Par conséquent, bien qu’il y ait un avantage, il est probablement perçu comme assez modeste.
L’autre côté, c’est le coût, l’adaptation rétroactive de DbC à un langage existant est probablement un changement trop important et très complexe à démarrer. Introduire une nouvelle syntaxe dans un langage sans casser l'ancien code est difficile. Mettre à jour votre bibliothèque standard existante pour utiliser un changement d'une telle ampleur coûterait cher. Nous pouvons donc en conclure que l’implémentation de fonctionnalités DbC dans un langage existant a un coût élevé.
Je voudrais également noter que les concepts qui sont à peu près des contrats pour des modèles, et donc quelque peu liés à DbC, ont été abandonnés de la dernière norme C ++ car même après des années de travail sur ces derniers, il a été estimé qu'ils en avaient encore besoin. Il est trop difficile de mettre en œuvre ces types de changements de grande envergure et généraux.
la source
DbC serait utilisé plus largement si les contrats pouvaient être vérifiés au moment de la compilation, de sorte qu'il ne serait pas possible d'exécuter un programme qui violerait un contrat.
Sans le support du compilateur, "DbC" n'est qu'un autre nom pour "vérifier les invariants / hypothèses et lever une exception en cas de violation".
la source
J'ai une explication simple, la plupart des gens (y compris les programmeurs) ne veulent pas de travail supplémentaire à moins de le juger nécessaire. Programmation avionique où la sécurité est considérée comme très importante Je n'ai pas vu la plupart des projets sans elle.
Mais si vous envisagez de programmer un site Web, un ordinateur de bureau ou un appareil mobile, les plantages et les comportements inattendus ne sont parfois pas considérés comme mauvais et les programmeurs éviteront tout travail supplémentaire lorsque le signalement des bogues et leur résolution ultérieure sont jugés suffisants.
C’est probablement la raison pour laquelle, à mon avis, Ada n’a jamais repris contact avec l’industrie de la programmation aéronautique, car il nécessite plus de travail de codage, même si Ada est un langage génial et si vous souhaitez construire un système fiable, c’est le meilleur langage pour le travail langage basé sur Ada).
Les bibliothèques de contrats de conception pour C # étaient expérimentales et fournies par Microsoft. Elles sont très utiles pour créer des logiciels fiables, mais elles n’ont jamais pris de l’élan sur le marché, sans quoi elles auraient déjà été intégrées au langage C #.
Les assertions ne correspondent pas à un support entièrement fonctionnel pour les conditions pré / post et invariant. Bien qu'il puisse essayer de les émuler, un langage / compilateur avec le support approprié effectue l'analyse de «l'arbre de syntaxe abstrait» et vérifie les erreurs de logique que de simples assertions ne peuvent pas.
Edit: j'ai fait une recherche et suivre une discussion connexe qui pourrait être utile: https://stackoverflow.com/questions/4065001/are-there-any-provable-real-weal-languages-scala
la source
Les raisons sont principalement les suivantes:
la source