Prog fonctionnelle
View All Tags
Cette fois, on va aller encore un peu plus loins : on va écrire notre propre monade ! N'ayez pas peur tout est sous contrôle !
Si vous faites du webflux, avec du code métier, allez y les yeux fermés !
Dans l'article précédent, on a parlé d'immutabilité qui limite une partie des effets de bord, en empêchant la modification de variable en dehors du scope de fonctions. Cette fois-ci, on va aller plus loins, en traitant : les exceptions, les IO, les dates ou les traitements aléatoires.
Dans le post précédent, on a vu les fondations de la programmation fonctionnelle. Ici, on va s'intéresser un peu plus en détail à l'immutabilité en java.
La version 8 du jdk a amené la programmation fonctionnelle en java, notamment, avec les fameuses lambda et les streams pour les collections.
Mais peut-on réellement faire de la prog fonctionnelle en java ? Dans ce post, on fera un tour de quelques notions de prog fonctionnelle et on verra ce qu'on peut faire en java.
Le "property based testing" est un type de tests souvent utilisé en programmation fonctionnelle pour valider des lois.
Il y a quelques années, j'avais testé jqwik, une librairie de property based testing en java, pour valider des lois sur une lib d'optics en java (ouais je sais, ça à l'air de ne rien vouloir dire cette phrase). Je n'étais pas allé plus loins que ça.
Cette année à Devoxx France 2025, j'ai assisté à un talk de Pierre Zemb "Et si on faisait du simulation-driven development ?" dans lequel il évoquait le property based testing pour tester du code métier.
Voyons ce que ça peut donner en java pour tester une application spring.
Dans les langages fonctionnels tels que java ou haskell, il est d'usage d'utiliser au maximum le compilateur pour éviter le plus tôt possible les bugs.
Avec l'arrivée du jdk 17, et notamment des sealed class et des record, java nous propose de nouvelles fonctionnalités pour utiliser encore plus le système de type et donc le compilateur.
L'approche "parse, don't validate" propose de créer des types riches pour représenter les données plutôt que d'utiliser les types primitifs comme String, Boolean etc et ainsi rendre impossible les états incohérents. Dans le cas d'une API, une fois le payload d'une requête parsé, c'est le compilateur qui reprend la main et valide le code pour vous.
Dans cet article, je vous propose, de suivre cette pratique en java et de voir où ça nous mène.