<
Media
>
Article

Java 17, le record & pattern matching c’est pour maintenant ?

7 min
24
/
03
/
2022


Promis juré, cet article n’est pas une liste des "nouvelles fonctionnalités de Java" (JLS[1] / JSR[2] / JEP[3]).

Depuis sa sortie en septembre 2021, les articles sur Java 17 pleuvent.

Ok, ça y est, on a bien compris que cette version est une LTS[4].

Mais c’est aussi bien plus que cela.
C’est une milestone de l’objectif ambitieux nommé
"Record and Array Pattern Matching".

Cet objectif est un ensemble de fonctionnalités synergiques :

  • Les <span class="css-span">instanceof</span> avec "Type Patterns" (dispo en 16)
  • Les Switch on Patterns (Java 17 preview, et probablement dispo en 19)
  • La déconstruction de <span class="css-span">record</span> (Peut-être Java 19 preview)
  • La déconstruction d’array (Java 19+ ?)
  • Les imbrications de patterns (pas de visibilité de dispo)

C’est donc de ces features dont on parle ici :

  • À quoi servent-elles ?
  • Comment et dans quels contextes les utiliser ?
  • Qu’apportent-elles à notre code ?

Et avec bien sûr des exemples de code !

Dans quels langages trouve-t-on déjà du pattern matching ?

Révolutionner Java, oui, mais pourquoi ?

Quand on souhaite améliorer un produit, on commence par se demander où les efforts seraient les plus bénéfiques.
Si on veut améliorer Java, on doit alors se demander "Que fait-on le plus souvent en Java, qui mériterait un upgrade ?"

Aujourd’hui le design de nos backend d’applications de gestion pousse autour d’une problématique :
Faire varier des comportements en fonction de cas d’usage

Dans ce genre d’application, quelle que soit l’architecture choisie ou le style dev, on se retrouve à un moment ou un autre à :

1. Modéliser notre domaine métierCela peut être fait dans un package spécifique avec des POJO, ou avec des <span class="css-span">Entity</span> JPA.
La seconde option est la plus répandue, mais ce n’est pas ma préférée. Je trouve que c’est une erreur de concevoir le business d’une application autour d’une base de données.2. Écrire des DTO

Dans l’idéal, un DTO est immutable (Il n’y a aucune raison de changer la représentation d’une donnée transmise à un moment T).
Le <span class="css-span">record</span> est la structure de données la plus appropriée.
Sinon, avant Java 14, on a les <span class="css-span">@Value</span> de Lombok.
On peut aussi se contenter de POJO mutables.

Dans nos applications modulaires, on peut avoir envie de partager ces structures de données entre des modules :

Modèle du domain Invoice

Et bien pour faire varier les comportements des actions affectant ces classes, la Programation-Orientée-Objets nous incite à ajouter des méthodes sur nos classes de domaine.

Par exemple, pour la domain-class <span class="css-span">Invoice</span>, le module <span class="css-span">Letter</span> pourrait vouloir ajouter une méthode <span class="css-span">calculateRemainingAmountToPay()</span>.
Le module <span class="css-span">Send</span> pourrait vouloir une méthode <span class="css-span">getRecipients()</span>.

Modèle de domaine avec Invoice et cas d’utilisation

<pre><code>class Invoice implements CalculableAmount, Sendable {
 private String label;
 private CodeInvoice code;
 private Client client;
 private Receipt receipt;
 private Devise amount;

 @Override
 public Integer calculateRemainingAmountToPay(){
   ...
 }

 @Override
 public List<Person> getRecipients(){
   ...
 }

 ...
}<code><pre>

Au bout d’un moment, notre domain-class <span class="css-span">Invoice</span> a beaucoup de méthodes issues de différents modules.
Le module <span class="css-span">Letter</span> utilise <span class="css-span">Invoice</span> et se retrouve à pouvoir appeler les méthodes du module <span class="css-span">Send</span> ; ce qui viole au moins :

Effet bonus : Quand on change <span class="css-span">Invoice</span> dans le cadre du contexte <span class="css-span">Letter</span>, on doit recompiler/relivrer aussi le contexte <span class="css-span">Send</span>.

Solution : séparer la logique métier des structures sur lesquelles elle agit

Pour y parvenir, on utilisait jusque-là au moins ces 3 patterns :

  • Le visitor pattern[5]
  • Le delegate pattern
  • Le pattern service-everywhere avec des méthodes à 8 arguments (un anti-pattern d’après moi), qui naît de la programmation procédurale dans un monde d’https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans[inversion de contrôle.]

Mais à présent avec Java 17, une quatrième solution élégante s’offre à nous : Le Pattern Matching.

Mais qu’est-ce que le pattern matching ?

Je pense qu’on ne peut pas couper à la définition de Wikipédia :

In computer science, pattern matching is the act of checking a given sequence of tokens for the presence of the constituents of some pattern.

— https://en.wikipedia.org/wiki/Pattern_matching

On a tendance à penser alors aux expressions régulières, mais non, il ne s’agit pas de cela.

Là, les patterns à matcher sont des structures de données :

  • Des classes
  • Des interfaces
  • Des array
  • Et bien sûr des records !

Je trouve que le cas du matching sur <span class="css-span">instanceof</span> avec Type-Pattern est le plus facile à comprendre.
Avant Java 17, on avait ça :

<pre><code>if (invoice instanceof PaidInvoice) {
 letterService.letter(((PaidInvoice) invoice));
 return;
}
if (invoice instanceof DueInvoice) {
 recoveryService.remind(((DueInvoice) invoice));
}<code><pre>

Et à présent :

<pre><code>if (invoice instanceof PaidInvoice paidInvoice) {
 letterService.letter(paidInvoice);
 return;
}
if (invoice instanceof DueInvoice dueInvoice) {
 recoveryService.remind(dueInvoice);
}<code><pre>

Ici le pattern à matcher est l’appartenance aux classes <span class="css-span">PaidInvoice</span> et <span class="css-span">DueInvoice</span>. On teste si l’instance a un des types, et un cast implicite est fait vers une "binding variable" (<span class="css-span">paidInvoice</span> ou <span class="css-span">dueInvoice</span>).

Comment le Pattern Matching remplace-t-il le visitor pattern ?

J’ai promis des exemples de code, les voici.

Voici l’implémentation du visitor pattern avec le modèle de <span class="css-span">Invoice</span> :

<pre><code>interface InvoiceVisitable {
 default void accept(InvoiceVisitor invoiceVisitor) {
   invoiceVisitor.visit(this);
 }
}

abstract class Invoice implements InvoiceVisitable {
}

class PaidInvoice extends Invoice {
}

class DueInvoice extends Invoice {
 private Integer reminderNumber = 0;

 public void incrementReminderNumber(){
   reminderNumber++;
 }

 public boolean hasAlreadyBeenReminded() {
   return reminderNumber >= 1;
 }
}

interface InvoiceVisitor {
 void visit(PaidInvoice paidInvoice);

 void visit(DueInvoice dueInvoice);
}

interface LetterService {
 void letter(PaidInvoice paidInvoice);
}

interface RecoveryService {
 void remind(DueInvoice dueInvoice);
}

record MainInvoiceVisitor(LetterService letterService, RecoveryService recoveryService) implements InvoiceVisitor {

 @Override
 public void visit(PaidInvoice paidInvoice) {
   letterService.letter(paidInvoice);
 }

 @Override
 public void visit(DueInvoice dueInvoice) {
   recoveryService.remind(dueInvoice);
 }
}

record InvoiceService(MainInvoiceVisitor mainInvoiceVisitor) implements InvoiceProcessing {

 public void handleInvoice(Invoice invoice) {
   invoice.accept(mainInvoiceVisitor);
 }
}<code><pre>

On observe que le rapport code utile / boilerplate n’est pas excellent.

Et maintenant :

<pre><code>record InvoiceService(LetterService letterService, RecoveryService recoveryService) implements InvoiceProcessing {

 public void handleInvoice(Invoice invoice) {
   if (invoice instanceof PaidInvoice paidInvoice) {
     letterService.letter(paidInvoice);
     return;
   }
   if (invoice instanceof DueInvoice dueInvoice) {
     recoveryService.remind(dueInvoice);
   }
 }
}<code><pre>

Le <span class="css-span">InvoiceService</span> se suffit à lui-même, et la lisibilité me semble très acceptable.

Mais avez-vous remarqué quelque chose dans ce dernier bout de code ?

Le cas où invoice est d’un autre type n’est pas géré !
Il existe une solution alternative (et meilleure je trouve) à lever une <span class="css-span">NotImplementedException</span>.

Les types scellés

C’est là que la fonctionnalité Java 15 de types scellés intervient.
Modifions un peu notre modèle :

<pre><code>abstract sealed class Invoice permits PaidInvoice, DueInvoice {
}

final class PaidInvoice extends Invoice {
}

final class DueInvoice extends Invoice {
 private Integer reminderNumber = 0;

 public void incrementerNombreReminder(){
   reminderNumber++;
 }

 public boolean hasAlreadyBeenReminded() {
   return reminderNumber >= 1;
 }
}<code><pre>

Traduction en français :Il n’existe que 2 types de Invoice possibles : <span class="css-span">PaidInvoice</span> et <span class="css-span">DueInvoice</span>.
Ces dernières ne peuvent être étendues.
Point.

Cela donne donc :

<pre><code>record InvoiceService(LetterService letterService, RecoveryService recoveryService) implements InvoiceProcessing {

 public void handleInvoice(Invoice invoice) {
   switch (invoice) {
     case PaidInvoice paidInvoice -> letterService.letter(paidInvoice);
     // case DueInvoice dueInvoice -> recoveryService.remind(dueInvoice);
   }
 }
}<code><pre>

J’ai commenté le cas de la DueInvoice afin d’observer ce que nous disent le compilateur et l’IDE :

java: the switch statement does not cover all possible input values IntelliJ
java compile error java 17 the switch statement does not cover all possible input values

On doit alors déclarer le <span class="css-span">Consumer<? extends Invoice></span> de tous les cas restants, ou bien les grouper dans un <span class="css-span">default</span> :

<pre><code>record InvoiceService(LetterService letterService, RecoveryService recoveryService) implements InvoiceProcessing {

 public void handleInvoice(Invoice invoice) {
   switch (invoice) {
     case PaidInvoice paidInvoice -> letterService.letter(paidInvoice);
     // case DueInvoice dueInvoice -> recoveryService.remind(dueInvoice);
     default -> LOGGER.info("Cool y a rien à faire pour le cas là !");
   }
 }
}<code><pre>

Avec cette syntaxe, le langage nous apporte une validation métier de plus à la compile time (soit plus tôt qu’à la runtime. Tout ce qui réduit la boucle de feedback est bénéfique).
C’est les TDDistes qui sont contents.

Et si on allait encore plus loin ?

Les Guarded Pattern

Allez, ajoutons une feature preview de Java 17 : un "Guarded Pattern"

<pre><code>record InvoiceService(LetterService letterService, RecoveryService recoveryService) implements InvoiceProcessing {
   public void handleInvoice(Invoice invoice) {
       switch (invoice) {
           case PaidInvoice paidInvoice -> letterService.letter(paidInvoice);
           case DueInvoice dueInvoice && dueInvoice.hasAlreadyBeenReminded() -> recoveryService.startRecovery(dueInvoice);
           case DueInvoice dueInvoice -> recoveryService.remind(dueInvoice);
       }
   }
}<code><pre>

Un "Guarded Pattern" permet d’ajouter à notre pattern des conditions sur les valeurs de l’objet matché en plus de son type.

Alors c’est très bien tout ça, mais l’objectif à terme du pattern matching va encore plus loin en ce qui concerne les records.

Reprenons notre exemple de <span class="css-span">Invoice</span>, mais considérons qu’elle vient d’arriver d’un <span class="css-span">Controlleur</span> sous forme de DTO (et donc de record) :

<pre><code>record Invoice(String code, String label, Integer amount, ZonedDateTime creationDate, ...){}<code><pre>

Je ne lui donne que quelques champs, mais considérons en plus qu’il y a en une vingtaine, une centaine, beaucoup…​

Quand je veux mapper cette invoice vers un usecase, alors ce dernier n’a très certainement besoin que de seulement quelques-uns de ces champs. Le code suivant serait donc une erreur de design :

<pre><code> 1@RestController
2class InvoiceControlleur {
3
4  @PostMapping
5  @ResponseStatus(HttpStatus.CREATED)
6  public Long create(@RequestBody Invoice invoice) {
7    Preconditions.checkNotNull(invoice);
8    notifyNewInvoiceUseCase.handle(invoice);
9    return invoiceService.handle(invoice)
10.  }
11}<code><pre>

Après Java 18 (En preview de Java 19 avec un peu de chance), on va pouvoir déconstruire des structures de données.

Qu’est-ce que la "déconstruction" ?

Ce concept a un objectif similaire au I de SOLID : la ségrégation.

Si je reçois un objet avec 43 champs alors que j’en ai besoin que de 2, la "deconstruction on pattern" va m’aider.

Regardons ça avec du code.

J’ai mon énorme dto Invoice :

<pre><code> record Invoice(
 String code,
 String libellé,
 Integer amount,
 ZonedDateTime dateCréation,
 ... // imaginez ici 39 autres champs
){}<code><pre>

Mais la règle métier que je veux appliquer ne porte que sur le code et le <span class="css-span">amount</span>. Je peux alors étendre le concept de <span class="css-span">instanceof</span> précédent, en lui ajoutant une déconstruction du Record "Invoice" :

<pre><code> if (object instanceof Invoice(String code, Integer amount)) {
 myUseCase.handle(code, amount);
}<code><pre>

Ici, <span class="css-span">type</span> et <span class="css-span">price</span> sont des "binding variables" générées implicitement si l’object match le pattern <span class="css-span">Product</span>.

Et ça sert à quoi ?

Cela apporte 2 bénéfices :

  1. Découplage
  2. Expressivité

Comparez plutôt le précédent code avec la méthode habituelle :

<pre><code>if (object instanceof Invoice) {
   Invoice invoice = ((Invoice) object);
   String type = invoice.getType();
   String price = invoice.getPrice();
   myUseCase.handle(type, price);
}<code><pre>

La déconstruction d’array

De la même manière que pour les <span class="css-span">record</span>, on va bientôt pouvoir déconstruire des array afin de :

  • Matcher sur sa structure (exemple : <span class="css-span">myArray.size() == 3</span>)
  • Binder ses éléments vers des variables

Voyons ce binding avec l’exemple d’un <span class="css-span">array d’Object</span>.

Mettons que, par convention :

  • Le premier élément "1345" est par convention le montant
  • Le deuxième élément "FAC" est le code du document

Alors voilà comment on pourrait appeler <span class="css-span">invoiceService.handle</span>, qui n’a besoin que de ces 2 champs, mais pas des suivants :

<pre><code>Object[] fields = { 1345, "FAC", "9834765", "user9475", "e45737645"  }

if (fields instanceof Object[] { Integer Price, String code }) {
 invoiceService.handle(price, code);
}<code><pre>

Et Java 18/19 alors ?

À l’écriture de ces lignes, Java 18 est en phase de release candidate.
Cela signifie que la liste de ces features est fixée.
En ce qui concerne le pattern matching, on y retrouve la JEP 420 : Pattern Matching for switch (Second Preview)
Cette seconde preview apporte des corrections de syntaxe et de compilation mineures, qui n’affectent pas les explications précédentes. Java 19 est en early-access avec une seule JEP.
J’espère y trouver la déconstruction de record/array/méthode en preview.

Conclusion

Qu’apporte à notre code ces nouvelles fonctionnalités ?

  • Plus de validation à la compile-time, et donc une boucle de feedback plus rapide.
  • Développer plus intuitivement (le compilateur nous dis ce qu’on a oublié)
  • Faire émerger de meilleurs designs

J’ai passé en revue les fonctionnalités phares du "record and array pattern matching", en appuyant sur "dans quels contextes les utiliser ?", "pourquoi les utiliser ?".
Les principales sont déjà dans Java 17, d’autres sont dans sa preview, et les restantes ne tarderont pas.
Cette révolution du langage est probablement au niveau de la révolution des Stream et de l’API Function de Java 8.

1. JLS : Java Language Specification

2. JSR : Java Specification Request

3. JEP : JDK Enhancement Proposal

4. LTS : Long Term Support

5. "Today, to express ad-hoc polymorphic calculations like this we would use the cumbersome visitor pattern". source : https://openjdk.java.net/jeps/405

Last updated 2022-03-17 17:47:59 +0100

No items found.
ça t’a plu ?
Partage ce contenu
Antoine Salesse

Si ça parle Java chez Younup, soyez sûr qu'Antoine n'est jamais très loin !

Spécialiste de Spring Boot et fan de Groovy - pour son langage intuitif, haut niveau et qui permet la métaprogrammation - il est toujours curieux de découvrir de nouvelles technos ou outils qui pourraient booster sa productivité.

Un peu de chocolat, du café et un pc qui tient la route, c'est tout ce dont il a besoin pour coder ! Pas possible de poireauter 4h par jour devant des loaders...

Mais Antoine n'est pas seulement fan de Bob Martin ou de designs modulaires, laissez-lui un après-midi pour customiser son jardin avec un nouveau cabanon ou karchériser sa terrasse.