J'ai vu cette citation dans beaucoup d'endroits :
"Il vaut mieux que 100 fonctions opèrent sur une structure de données que 10 fonctions sur 10 structures de données". -Alan Perlis
Mais je n'ai jamais vu d'explication sur la raison pour laquelle cela devrait être vrai. Est-ce simplement l'idée que vous devriez essayer de dériver les 9 autres structures de données à partir de la première pour éviter de dupliquer les données ? J'ai l'impression qu'il me manque un contexte.
La citation est tirée de l'ouvrage d'Alan Perlis Epigrammes sur la programmation qui a été publié en 1982.
La signification de cette citation est bien incarnée dans Lisp où il y a des multitudes de fonctions qui opèrent et traitent spécifiquement avec listes Les listes et l'assortiment de fonctions qui opèrent sur les listes permettent d'accomplir beaucoup de choses, ce qui les rend beaucoup plus puissantes que n'importe quelle structure de données à usage unique.
Lua comme autre exemple, utilise des tables pour simuler des classes . Pourquoi utiliser un tableau pour créer des objets au lieu de créer des classes et des objets au niveau du langage comme le font les langages orientés objet ? Puisque votre objet est maintenant une table, vous pouvez utiliser n'importe quel nombre de fonctions définies pour les tables sur votre objet, gratuitement ! Mieux encore, nous n'avons pas eu à encombrer le langage avec une syntaxe spécifique à la classe et à redéfinir les fonctions de la table que nous voulons pour notre classe.
Ce que Perlis a dit est définitivement un mode de pensée proéminent dans Lisp et dans programmation fonctionnelle en général. Ces 100 fonctions sur votre structure de données peuvent être composées ensemble de nombreuses façons uniques, puisqu'elles opèrent toutes sur la même structure de données, mais vous ne pouvez pas vraiment mélanger les 10 fonctions sur 10 structures de données aussi bien, puisqu'elles ont été définies uniquement pour fonctionner sur leur structure de données particulière.
Une variante plus moderne et plus simple de ce principe consiste à penser en termes de abstractions . Si nous codions en Java, préféreriez-vous écrire une centaine de fonctions sur le Liste ou le même ensemble de dix fonctions, une fois pour ArrayList, une fois pour LinkedList, une fois pour .....
Structure et interprétation des programmes d'ordinateur (SICP) répond à votre question comme ci-dessous :
Vous pouvez voir le contenu original de la version en ligne du livre ici
EDIT (inclus dans le commentaire) :
"En Pascal, la pléthore de structures de données déclarables induit une spécialisation au sein des fonctions." La spécialisation est mauvaise car elle inhibe la "sérendipité"/créativité - je dirais - avec mes propres mots.
En d'autres termes, si les fonctions sont trop spéciales, elles ne peuvent pas être réutilisées d'une manière qui n'était pas connue au moment de la création de la fonction.
Un bon exemple est fold ( https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Foldable.html ) qui est une fonction générale d'ordre supérieur, indifférente à la structure des données. Elle peut être utilisée sur un arbre, par exemple
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a).
Je n'en suis pas certain, mais cela semble être un argument en faveur d'une meilleure encapsulation et cohésion. Vous ne fournissez pas de citation ou de date, et je suis trop paresseux pour chercher moi-même sur Google, mais je parie qu'Alan Perlis l'a dit avant que la programmation orientée objet ne s'impose dans le courant dominant. Les styles procéduraux permettaient que des données éparpillées partout soient exploitées par n'importe quelle fonction.
Si vous remplacez "une structure de données" par "une classe", cela a du sens dans une optique orientée objet.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
