Comment Clojure aborde-t-il la séparation des préoccupations?

Question

Comment Clojure aborde-t-il la séparation des préoccupations? Puisque le code est données, les fonctions peuvent être passées en paramètres et utilisées comme retours ...

Et, comme il y a ce principe "Mieux 1000 fonctions qui fonctionnent sur 1 structure de données, que 100 fonctions sur 100 structures de données" (ou quelque chose comme ca). Je veux dire, emballer tout une carte, lui donner un mot-clé comme clé, et c'est tout? fonctions, scalaires, collections, tout ...

L'idée de Separation of Concerns est implémentée, en Java, au moyen d'Aspects (programmation orientée aspect) et d'annotations. C'est mon point de vue sur le concept et pourrait être quelque peu limité, alors ne le prenez pas pour acquis.

Quelle est la bonne voie (voie idiomatiques) d'aller sur dans Clojure, pour éviter les WTFs des autres programmeurs _

Answer 1

Dans un langage fonctionnel, la meilleure façon de gérer la séparation des préoccupations est de convertir un problème de programmation dans un ensemble de transformations sur une structure de données. Par exemple, si vous écrivez une application Web, l'objectif global est de prendre une requête et de la transformer en une réponse, ce qui peut être considéré comme une simple transformation des données de la requête en données de réponse. (Dans une application Web non triviale, les données de départ incluraient probablement non seulement la demande, mais aussi les informations de session et de base de données). La plupart des tâches de programmation peuvent être envisagées de cette manière. Chaque "préoccupation" serait une fonction dans un "pipeline" qui aide à rendre la transformation possible. De cette manière, chaque fonction est complètement découplée des autres étapes. Notez que cela signifie que vos données, en subissant ces transformations, doivent être riches en structure. Essentiellement, nous voulons mettre toute l'intelligence de notre programme dans les données, pas dans le code. Dans un programme fonctionnel compliqué, les données aux différents niveaux peuvent être assez complexes pour ressembler à un langage de programmation. C'est là qu'intervient l'idée de «langages spécifiques au domaine».

Clojure offre un excellent support pour manipuler des structures de données hétérogènes complexes, ce qui rend cela moins lourd que cela puisse paraître (il n'est pas lourd du tout si bien fait)

En outre, le soutien de Clojure pour les structures de données paresseuses permet à ces structures de données intermédiaires pour être réellement (conceptuellement) de taille infinie, ce qui rend ce découplage possible dans la plupart des scénarios. Voir l'article suivant pour savoir pourquoi avoir des structures de données infinies est si précieux dans cette situation: http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf

Cette approche «pipeline» peut gérer 90% de vos besoins pour séparer les préoccupations. Pour les 10% restants, vous pouvez utiliser des macros Clojure, qui, à un niveau élevé, peuvent être considérées comme un outil très puissant pour la programmation orientée aspect.

C'est ainsi que je crois que vous pouvez mieux découpler les préoccupations dans Clojure - Notez que «objets» ou «aspects» ne sont pas des concepts vraiment nécessaires dans cette approche.