Dans les précédents articles, nous avons étudié 3 refactorings permettant d’améliorer la lisibilité de code manipulant le type Future[Option[T]].

L’application du principe de séparation des responsabilité a permis une première amélioration, l’utilisation d’exceptions métier est une solution dans certains cas mais sacrifie une partie de l’information de typage.

Finalement l’utilisation d’un type ad hoc composant les propriétés d’une Future et d’une Option s’est avéré être un parfait complément à la séparation initiale.

Le seul défaut de cette dernière approche est le besoin de maintenir ce type et de construire un nouveau type pour chaque nouvelle composition: FutureO (Future et Option), FutureL (Future et List), etc. Ces types ne sont pas spécifiques à un projet et idéalement devraient être extraits dans une bibliothèque. Il s’avère qu’une telle bibliothèque existe déjà.

Dans cet article, le dernier de cette série, je vous propose un refactoring utilisant les MonadTransformer de Scalaz 7.x.

Dans les précedents articles, nous avons étudié comment améliorer la lisibilité de code manipulant le type Future[Option[T]] en appliquant le principe de séparation des responsabilité et en utilisant des exceptions métier.

Ces deux approches, relativement simples ont toutes deux montré des limites: la première mélange le traitement de cas d’erreurs avec le traitement de cas normaux, la seconde perd de l’information au niveau du système de type et nécessite une connaissance de précise de l’implémentation ou une documentation détaillée pour pouvoir être correctement manipulée.

Dans cet article je vous propose d’explorer une piste proposée par la programmation fonctionnelle: la composition du type Future et du type Option dans un type ad hoc.

Dans le précedent article, nous avons vu comment mitiger les effets des signatures de type Future[Option[T]] sur la lisibilité du code. L’extraction d’un ResultMapper et l’utilisation du pattern matching ont permis de séparer les différentes problématiques du code initial.

En conclusion je faisait remarquer que la répartition des traitements succès/erreur dans le mapper était suspecte. Elle devient problématique lorsque vous voulez coordonner plusieurs appels à des services ayant ce type de signature, le happy path est alors pollué par l’extraction des valeurs dans les couches successives de type conteneurs.

Je vais maintenant montrer que l’utilisation d’exceptions métier est une façon de regrouper les cas d’erreurs dans le même bloc et de conserver un happy path simple.

Depuis quelques temps je travaille sur une application Play 2 en scala. Nos APIs d’accès aux données sont asynchrones et renvoient toutes des Futures[T]. Avec une telle API, on se retrouve vite avec des signatures de type Future[Option[T]]. Transformer proprement un tel résultat vers des réponses HTTP n’est pas forcément évident et peut amener de la duplication même dans des cas simples. Dans cet article nous allons voir une façon d’éviter ce problème.

Nous savons maintenant installer vagrant sur osx et utiliser vagrant pour construire une vm. Ces derniers temps le nombre de technologies différentes utilisées dans les projets à augmenté. La philosophie “Best tool for the job”, que je soutiens totalement, encourage cette prolifération.