Comment organiser des programmes fonctionnels
Duplicata possible:
Programmation fonctionnelle vs OOP
Comment écrire du code gérable avec une programmation fonctionnelle?
Dans la POO, votre unité d'organisation de base pour le code est la classe. Une méthodologie fréquemment utilisée en Java, C # et langages similaires consiste à organiser votre code autour d'un fichier pour chaque classe avec le nom de fichier suivant le nom de la classe.
Vous pouvez considérer chacune de ces classes comme une unité d'organisation pour regrouper un seul concept.
Ces classes sont dans des espaces de noms qui suivent souvent la structure de répertoires des fichiers dans la solution/projet. Les espaces de noms sont un autre niveau d'organisation.
Comment les grands projets dans les langages fonctionnels sont-ils généralement organisés?
Comment déterminez-vous comment diviser vos fonctions en différents fichiers?
D'autres unités de regroupement à côté des fichiers sont-elles utilisées?
Comment le code est-il généralement organisé dans un seul fichier?
Je soupçonne que cela dépend de la langue. En ce qui concerne la programmation fonctionnelle, j'ai surtout essayé Haskell, donc je vais expliquer comment cela fonctionne là-bas.
Le code Haskell est organisé en "modules" qui sont fondamentalement de simples collections de fonctions et de types de données. Chaque module est un fichier unique. Un module est un mélange entre une classe Java et un package Java - la portée exacte de ce qu'un module fait varie. Un module contrôle également les fonctions et les constructeurs de types à exporter et ceux à masquer; ceci est similaire à private et public en Java.
Dans mes propres programmes, j'aime que les modules fassent ne chose, sémantiquement; cela les rend comme une classe Java sauf qu'ils peuvent définir plusieurs types de données. Les modules que j'utilise dans la bibliothèque standard, comme Data.List, Sont plus comme des packages - ils fournissent un ensemble de fonctions utilitaires similaires. Ceci est également très similaire aux classes statiques Java comme Java.util.Arrays.
Les modules sont également comme des packages Java en ce sens qu'ils peuvent être imbriqués pour plus de clarté (je ne pense pas que cela ait un effet sur le code lui-même). En général, pour un seul projet, je lui donne un nom (disons Project) et je fais participer tous mes modules (par exemple Project.Parse Et Project.Run). Si j'écrivais du code qui ressemblait plus à une bibliothèque qu'à une application, je l'organiserais en fonction de ce qu'il faisait, comme Data.List Ou Control.Monad. Une différence majeure par rapport aux autres langues est que Haskell encourage à limiter IO et à tout mettre en un seul endroit. Un grand nombre de modules ne font pas IO du tout, et pour tout projet donné, j'aime avoir autant de modules purs que possible.
À titre d'exemple, je travaille sur un langage de programmation simple que j'appelle TPL (sans raison valable). Pour cela, j'ai créé deux modules simples: TPL.Parse Qui définit la représentation interne du langage et comment l'analyser, et TPL.Run Qui exécute l'interpréteur et traite des variables et des entrées/sorties. Pour réellement compiler et exécuter le code, il y a généralement un module Main qui est finalement le point d'entrée du programme.
Il existe une grande liberté dans l'organisation des fonctions au sein d'un fichier; c'est exactement ce que j'aime faire. Je définis mes types de données vers le haut, avant de les utiliser ailleurs. Juste après avoir défini les types de données, j'implémente tout ce dont j'ai besoin pour les intégrer à leurs classes de types appropriées - c'est un peu comme implémenter une interface. Ensuite, je poursuis avec la logique et diverses fonctions d'assistance, le cas échéant. Enfin, j'aime avoir toutes mes fonctions IO tout en bas se terminant par main. Cela montre clairement ce qui fait tout IO et où le programme démarre.
Donc, en résumé: les fonctions sont contenues dans des modules, chacun étant constitué d'un seul fichier. Plusieurs modules peuvent constituer un programme ou une bibliothèque; le premier inclut généralement un module Main qui est son point d'entrée. Dans un fichier, il existe différentes options d'organisation, mais je préfère regrouper les types de données vers le haut, IO vers le bas et la logique au milieu.