Modèles de conception pour les langages hybrides OO fonctionnels?

Existe-t-il déjà un recueil de bonnes pratiques pour des langues comme Scala?

J’ai trouvé un travail sur les modèles de conception pour les langages fonctionnels, les modèles de conception pour la programmation stratégique fonctionnelle . Il existe des modèles de conception GoF pour les langues OO. Mais existe-t-il des modèles pour les hybrides OO fonctionnels? Tout ce que j’ai vu, c’est cette liste. Ce qui est connu?

Deux modèles de Bill Venners; Je pense que les deux sont très utilisés dans ScalaTest:

Trait empilable (structure similaire au modèle de décorateur, sauf qu’il s’agit d’une décoration destinée à la composition d’une classe plutôt qu’à une composition d’object).

Trait désintéressé (permet aux concepteurs de bibliothèques de fournir des services auxquels leurs clients peuvent accéder via des mixins ou des importations).

Type constructeur sécurisé

Des solutions extensibles indépendantes au problème de l’expression – tout comme «l’abstraction de composants évolutifs», ce n’est pas un catalogue de modèles, mais il traite également de problèmes similaires (par exemple, le modèle de visiteur)

Déprécier le modèle d’observateur – une alternative à l’observateur.

Nous pouvons également considérer l’émulation Scala des classes de type Haskell comme un modèle de conception. La première description (que j’ai pu trouver au moins) se trouve dans les classes de type Poor Man . Certaines entrées de blog sont également disponibles avec ce sujet.

Et je pense que je ne me trompe pas complètement si je mentionne également les différentes monades. Vous pouvez trouver beaucoup de ressources pour les traiter.

Bien que ce ne soit pas directement un catalogue de modèles de conception, le document ” Scalable Component Abstractions ” (Martin Odersky; Matthias Zenger) examine trois éléments constitutifs de composants réutilisables:

  • membres de type abstrait,
  • types d’authentification explicites, et
  • composition de mixin modulaire.

Et il revisite plusieurs modèles de conception (publication / abonnement, sujet / observateur, contexte / composant) pour illustrer et comprendre quels éléments du langage sont essentiels à la réalisation de systèmes de composants évolutifs et dynamics.

Un motif fréquemment observé, qui nécessite un nom, consiste à créer des abstractions de contrôle avec des listes de parameters et des parameters de nom curry.

def command(expr: T)(block: => Unit) {...} 

céder

 command (expr) { block } 

Dans la mesure où tout langage object-fonctionnel va rapidement acquérir une bibliothèque d’acteurs, un grand nombre de modèles basés sur les acteurs sont probablement qualifiés pour cette question. Presque tous les modèles des modèles d’ intégration d’entreprise de Bob Martin sont refondables en termes d’acteurs, les modèles tels que Load Balancer, Message Filter, Content-Based Router et Content Enricher étant particulièrement courants dans les systèmes conçus autour d’acteurs grossiers.

En étroite relation, vous souhaiterez peut-être explorer des structures de données telles que définies dans des langages purement fonctionnels (ou hybrides). D’une part, la possibilité de traiter les fonctions comme des valeurs de première classe rend certains modèles (comme visiteur , méthode de modèle ou décorateur ) inutiles dans certains contextes (pas tous). Deuxièmement, les structures de données (et les algorithmes qui les gèrent) sont soit la structure des modèles de conception, soit présentent certains problèmes que les modèles de conception tentent de résoudre, voir l’article de Wikipedia Purement fonctionnel .

Mieux encore, je vous renvoie à la thèse d’ Okasaki sur les structures de données purement fonctionnelles .