Tutoriel sur des patterns d'implémentation avec les enums Java

| Laurent Claisse (Zenika) | Zenika |

Cet article présente des patterns d'implémentation avec les enums Java.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum Commentez .

- Titre : Tutoriel sur des patterns d'implémentation avec les enums Java

- Auteurs : Laurent Claisse (Zenika), Zenika

- Parution : 24 avril 2015

- Licence : Copyright ® 2015 Laurent Claisse. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Les enums Java : l'intégration du pattern « type-safe enumeration » dans le langage

- III. Utilisations originales des enums Java

- III-A. L'enum singleton

- III-A-1. Le singleton naïf

- III-B. L'enum singleton stateful

- IV. L'enum « static class »

- V. Le vif du sujet : les Enums polymorphiques

- V-A. Variation : implémentation complète

- V-B. Variation : implémentation partielle

- V-C. Variation : enums du domaine avec inversion de dépendance

- VI. Conclusion et remerciements

I - Introduction

Bien que les enums soient apparues en Java 5, elles restent relativement méconnues. Voyons donc quelques patterns d'implémentation. On commence par quelques points techniques (avertissement : certains sont plus des curiosités qu'autre chose) puis on aborde le pattern le plus important et le plus sous-utilisé : les enums polymorphiques.

II - Les enums Java : l'intégration du pattern « type-safe enumeration » dans le langage

Pour rappel, les enums Java sont complètement différentes des enums C#. Les enums C# sont des « value types » (comme les struct/int/Date…), représentant des alias d'int, et peuvent être combinées en bitmask. Leur philosophie est donc beaucoup plus proche des enums C++ (même si C++ 11 apporte les 'enums class' qui semblent aller plus loin qu'un simple alias d'int). Les enums Java sont l'aboutissement d'un processus différent, l'incarnation en feature d'un langage de ce qui était autrefois un pattern à implémenter par le programmeur : la 1re édition de « Effective java », qui précède l'arrivée de Java 5, détaille l'implémentation correcte en Java du pattern d'implémentation « type-safe enumerations ». Il s'agit d'un processus fréquent d'évolution d'un langage : ainsi, le pattern publish/subscribe devient une feature du langage en C#, le pattern prototype devient une feature du langage en JavaScript, etc.

À noter que l'implémentation manuelle des type-safe enums n'est pas du tout triviale : elle doit non seulement interdire l'instanciation par constructeur d'instances ne faisant pas partie de la liste des valeurs d'enum, mais aussi l'instanciation par le biais des mécanismes extralinguistiques (hors langage) : réflexivité, désérialisation et clonage.

Contrairement aux enums de type « alias d'int », les « type-safe enums » présentent les avantages suivants :

- Il n'est pas possible d'en obtenir une instance qui ne fasse pas partie de la liste des « enum constants », contrairement à C# où il est possible de faire +1 sur une enum (sans échec à la compilation ni au runtime).

- Elles sont polymorphiques, chaque valeur peut implémenter différemment une méthode définie par l'enum, ou par une interface implémentée par l'enum.

III - Utilisations originales des enums Java

Les deux patterns suivants ne sont pas fondamentaux, mais juste des techniques d'implémentation intéressantes dans certains cas. Ces sujets plus « légers » servent d'apéritif avant de voir une technique plus générale qui, elle, peut améliorer votre design objet global : les enums polymorphiques.

III-A - L'enum singleton

III-A-1 - Le singleton naïf

NaiveSingleton.java

1. /**

2. * L'implémentation naïve du singleton offre moins de garanties que l'enum,

3. * surtout pour un type sérialisable.

4. */

5. public class NaiveSingleton implements Serializable {

6. private NaiveSingleton() {}

7. public static final NaiveSingleton instance = new NaiveSingleton();

8. }

Il maintient bien la garantie d'instance unique en empêchant l'instanciation par constructeur depuis une autre classe, mais ne protège pas contre les instanciations par les mécanismes extralinguistiques : invocation du constructeur par réflexion, copie par sérialisation (si Serializable), clone (peu vraisemblable certes).

Les enums sont un singleton idéal, car le code généré par javac interdit ces tentatives : comme le dit bien Effective java,

Item 3: Enforce the singleton property with a private constructor or an enum type As of release 1.5, there is a third approach to implementing singletons. Simply make an enum type with one element :

Elvis.java

1. // Enum singleton - the preferred approach

2. public enum Elvis {

3. INSTANCE;

4. }

This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.

L'auteur considère cette façon de faire comme la meilleure implémentation d'un singleton, et non comme une simple ruse. S'agissant de Josh Bloch j'ai tendance à le croire, je pense que c'est seulement l'habitude qui nous fait parfois considérer cette utilisation des enums comme bizarre.

Exemple :

Factory.java

1. /**

2. * Un singleton stateless.

3. * Java Puzzlers suggère d'utiliser une enum pour être sûr à moindres frais

4. * que cette enum en est vraiment une.

5. */

6. public enum Factory {

8. instance;

10. public Object create() {

11. return new Object();

12. }

13. }

III-B - L'enum singleton stateful

Il est déconseillé d'utiliser les enums stateful, pour les mêmes raisons que celles qui conduisent à décourager l'utilisation de singletons stateful :

- Dépendance à l'ordre d'initialisation (indéterminisme) : l'état des singletons dépend de l'ordre dans lequel ils ont été initialisés. Or, cet ordre est difficilement maîtrisable, car déterminé au runtime par la séquence d'invocations.

- Problèmes découlant de la création de variables globales statiques (pas d'encapsulation, fuites mémoire…).

De plus, même si les « typesafe enums » sont très différentes des enums « alias d'int », on s'attend quand même implicitement à ce qu'elles soient immutables.

Si on a besoin de singletons statefuls, il vaut mieux utiliser des beans Spring, pour lesquels le conteneur prend en charge l'initialisation, ce qui évite au moins le problème de l'ordre d'initialisation (s'il y a un cycle, Spring nous le signale au démarrage).

IV - L'enum « static class »

Ce pattern est plus une curiosité qu'autre chose. Java n'a pas de « top-level static class » au sens de C# (classes dont le compilateur s'assure que toutes les méthodes sont statiques).

L'enum sans valeurs est un pattern d'implémentation Java qui émule ces classes (qu'on pourrait facilement avoir en Java dans un « project coin 2 » via un changement de javac, mais les concepteurs de Java doivent avoir peur d'ajouter à la confusion qui entoure déjà les « static nested class » vs « inner class »).

Maths

1. public enum Maths {

3. ;//Une enum commence toujours par la déclaration de ses instances (les "enum constants");

4. //ici il n'y en a aucune mais le bloc est quand même obligatoire.

6. public static double PI = 4*java.lang.Math.atan(1.0D); //tan(pi/4)=1 cf. le cercle trigonométrique

8. public static double cos(double radians) {

9. return 0D; //TODO

10. }

12. //Impossible à appeler

13. public double toto() {return 999D;}

14. }

L'émulation n'est pas complète, car on peut quand même écrire une méthode non statique, mais au runtime on est sûr de ne pas invoquer cette méthode. Dans un sens, la garantie est même supérieure au pattern habituel :

1. private Math(){throw new UnsupportedOperationException();}

, qui permet de rentrer dans le constructeur (même si c'est pour crasher tout de suite), et qui est un peu plus verbeux.

V - Le vif du sujet : les Enums polymorphiques

Rentrons maintenant dans le vif du sujet avec ce pattern extrêmement puissant. Comme expliqué en introduction, contrairement à C# où ce sont des « value types » de même que les structs ou les types « primitifs », les enums Java sont polymorphiques. Il s'agit donc de « vrais objets » qu'on peut utiliser pour implémenter les design patterns faisant appel au dynamic dispatch, et ainsi éviter le code procédural (switch sur la valeur de l'enum). Un cas fréquent est l'implémentation du pattern Strategy du GOF.

V-A - Variation : implémentation complète

Dans cette variation du pattern, il n'existe pas d'implémentations non-enums. Si on a besoin d'une autre implémentation, on ajoute une constante à l'enum, qui contient toutes les implémentations de la stratégie possibles/connues/intéressantes (pour l'instant). Les implémentations enum constants évitent la multiplication de singletons. Ces enums sont typiquement stateless.

BinaryOperation.java

1. package cla.enums.patterns.strategy.complete;

3. public interface BinaryOperation {

5. double apply(double d1, double d2);

7. public enum ArithmeticOperation implements BinaryOperation {

9. PLUS("+") {

10. @Override public double apply(double d1, double d2) {

11. return d1 + d2;

12. }

13. },

15. MINUS("-") {

16. @Override public double apply(double d1, double d2) {

17. return d1 - d2;

18. }

19. },

21. TIMES("*") {

22. @Override public double apply(double d1, double d2) {

23. return d1 * d2;

24. }

25. },

27. DIVIDED_BY("/") {

28. @Override public double apply(double d1, double d2) {

29. return d1 / d2;

30. }

31. },

33. ;

35. private final String symbol;

36. private ArithmeticOperation (String symbol) {this.symbol = symbol;}

38. @Override public String toString() {

39. return this.symbol;

40. }

41. }

43. }

45. public class BinaryOperationTest {

47. @Test public void plus() {

48. assertEquals(

49. 3D,

50. PLUS.apply(1D, 2D),

51. 0D

52. );

53. }

55. @Test public void minus() {

56. assertEquals(

57. -1D,

58. MINUS.apply(1D, 2D),

59. 0D

60. );

61. }

63. @Test public void times() {

64. assertEquals(

65. 6D,

66. TIMES.apply(2D, 3D),

67. 0D

68. );

69. }

71. @Test public void dividedBy() {

72. assertEquals(

73. 2D,

74. DIVIDED_BY.apply(6D, 3D),

75. 0D

76. );

77. }

79. @Test public void printPlus() {

80. assertEquals(

81. "+",

82. PLUS.toString()

83. );

84. }

86. @Test public void printMinus() {

87. assertEquals(

88. "-",

89. MINUS.toString()

90. );

91. }

93. @Test public void printTimes() {

94. assertEquals(

95. "*",

96. TIMES.toString()

97. );

98. }

100. @Test public void printDividedBy() {

101. assertEquals(

102. "/",

103. DIVIDED_BY.toString()

104. );

105. }

106. }

V-B - Variation : implémentation partielle

Dans ce pattern, il existe d'autres implémentations, non-enums. Les implémentations enum constants évitent la multiplication de singletons. Ces enums sont typiquement stateless, alors que les implémentations non-enums ne le sont pas forcément (ex. une implémentation avec cache).

Étant données les deux classes :

Record.java

1. /**

2. * Une entité du domaine

3. */

4. public class Record {

6. public boolean  logicallyDeleted;

8. //Exemple peu réaliste mais simple ;

9. //dans la réalité la suppression physique ne serait sûrement pas implémentée par un flag mais par une suppression du disque/BD.

10. public boolean physicallyDeleted;

12. }

PhysicalDeleter.java

1. public interface RecordEnv {

3. public interface PhysicalDeleter {

4. void deletePhysically(Record r);

5. }

6. public interface LogicalDeleter {

7. void deleteLogically(Record r);

8. }

10. default PhysicalDeleter physicalDeleter() {

11. return (Record r) -> r.physicallyDeleted=true;

12. }

13. default LogicalDeleter logicalDeleter() {

14. return (Record r) -> r.logicallyDeleted=true;

15. }

17. }

Dans ce contexte, on peut avantageusement représenter certaines stratégies d'effacement d'une ligne par des enums :

RecordDeletionStrategy.java

1. public interface RecordDeletionStrategy {

3. /**

4. * L'unique méthode, ce qui est le plus fréquent pour une stratégie

5. */

6. void deleteRecord(Record r, RecordEnvironment env);

8. /**

9. * Les "enums dégénérées" sont une sous-variante du pattern,

10. * dans laquelle les enum constants représentent des implémentations non opérationnelles,

11. * utilisables comme Null Object (Fowler, POEA) ou comme fake object de test.

12. * Quelques exemples de ces fakes objects:

13. */

14. public enum DegenerateImpls implements RecordDeletionStrategy {

16. /**

17. * Null object/dummy.

18. */

19. NOOP {

20. @Override public void deleteRecord(Record r, RecordEnvironment env) {

21. ;

22. }

23. },

25. /**

26. * Implémentation par défaut d'une opération optionnelle (cf. le Collections framework du JDK).

27. */

28. UNSUPPORTIVE {

29. @Override public void deleteRecord(Record r, RecordEnvironment env) {

30. throw new UnsupportedOperationException();

31. }

32. },

34. /**

35. * Simule un problème, pour les tests de gestion d'erreur par exemple.

36. */

37. DEFECTIVE {

38. @Override public void deleteRecord(Record r, RecordEnvironment env) {

39. throw new RuntimeException();

40. }

41. },

43. ;

44. }

46. /**

47. * Les "implémentation connues" sont une autre sous-variante du pattern,

48. * où les enum constants représentent des implémentations opérationnelles fournies par l'API,

49. * mais qui peuvent être complétées par des implémentations de l'application.

50. */

51. public enum WellKnownImpls implements RecordDeletionStrategy {

53. /**

54. * Fait un delete en BD (par ex.)

55. */

56. PHYSICAL_DELETION {

57. @Override public void deleteRecord(Record r, RecordEnvironment env) {

58. env.physicalDeleter().deletePhysically(r);

59. }

60. },

62. /**

63. * Met le flag 'DELETED' à true

64. */

65. LOGICAL_DELETION {

66. @Override public void deleteRecord(Record r, RecordEnvironment env) {

67. env.logicalDeleter().deleteLogically(r);

68. }

69. },

71. ;

72. }

73. }

V-C - Variation : enums du domaine avec inversion de dépendance

DI veut dire « dependency injection », mais est aussi parfois utilisé comme abréviation de « dependency inversion ». L'inversion de dépendance consiste à faire dépendre la couche technique de la couche métier au lieu de l'inverse.

Ceci permet d'introduire de façon non intrusive les préoccupations techniques dans l'application (une autre approche est l'AOP mais cette dernière est plus lourde à mettre en place). Le but de cette approche est d'éviter de polluer le code métier avec des préoccupations techniques (on constate souvent que celles-ci ont tendance à envahir le code supposément métier, jusqu'à en constituer la majorité). Un autre objectif est d'éviter les dépendances croisées entre les packages métier et les packages techniques.

En effet, la dépendance des packages métier vers les packages techniques est à priori un obstacle au Domain Driven Design qui préconise de mettre le plus possible de logique métier dans les classes qui représentent des entités du domaine. L'inversion de dépendance permet de contourner cet obstacle en introduisant dans la couche métier une abstraction, significative du point de vue de la couche métier, des services techniques.

Cette abstraction doit :

- être dans le même package que les entités métier, pour éviter une dépendance de packages métier-->technique ;

- avoir un nom métier et non technique, pour ne pas introduire de dépendance conceptuelle métier-->technique.

Exemple : dans le package model, Item peut dépendre de l'abstraction nommée Items, ItemsEnvironnement, ItemsRepository, mais pas de ItemsDB.

Plus précisément, le package métier com.toto.modele contient XXXEntity et XXXEnvironment/XXXs/XXXRepository (où XXX représente des trains, des entrepôts de carottes…), et le package technique contient l'implémentation com.toto.services contient XXXServicesImpl (par ex. un bean Spring transactionnel). La dépendance est donc bien dans le sens technique-->métier.

Prenons le cas de deux entités du modèle du domaine :

Item.java

1. package cla.enums.patterns.with.di.model;

2. /**

3. * Une entité du domaine.

4. * Ici son seul intérêt dans l'exemple est d'être agrégée par <tt>Bill</tt>.

5. */

6. //@Entity

7. public class Item {

8. public long priceWithoutShipping;

9. public double weight;

10. }

12. /**

13. * Une entité du domaine.

14. * <p>

15. * Elle colocalise état et logique métier,

16. * contrairement à l'antipattern fréquent des "entités étiques" (squelettiques).

17. * Le livre "domain-driven design" décrit cet antipattern dans lequel

18. * les entités ressemblent à des structs sans logique métier,

19. * laquelle est alors principalement contenue dans des "transaction scripts"

20. * (typiquement de longues méthodes procédurales dans un composant "frontière",

21. * comme un web service, un EJB remote, un bean Spring transactionnel...)

22. * </p>

23. * <p>

24. * L'inconvénient principal de cet antipattern est que comme la couche objet n'a pas d'épaisseur,

25. * on perd tous les avantages de la modélisation objet.

26. * </p>

27. * <p>

28. * Le livre explique en outre que la fréquence de cet antipattern s'explique

29. * par une difficulté technique : la plupart du temps, pour réaliser une logique métier non triviale,

30. * les objets du domaine auraient besoin de dépendre de composants techniques ou frontière

31. * (frontière au sens de boundary du pattern EE entity/control/boundary).

32. * C'est là que réside la difficulté, car d'autre part les composants frontière dépendent toujours

33. * des entités du domaine; on aboutirait alors à une dépendance croisée entre les packages

34. * <tt>cla.enums.patterns.with.polymorphism.and.di.model</tt> et

35. * <tt>cla.enums.patterns.with.polymorphism.and.di.services</tt>.

36. * La façon la plus simple ___mais pas la meilleure___ de s'affranchir de cette difficulté

37. * est de mettre toute la logique métier dans les composants frontière,

38. * et on arrive alors à l'antipattern décrit (des transaction scripts de 300 lignes).

39. * </p>

40. * <p>

41. * Une solution plus satisfaisante est d'utiliser l'inversion de dépendance,

42. * qui consiste à remplacer la dépendance entre deux packages par une dépendance

43. * des deux envers une abstraction commune, contenue dans le package métier

44. * (ici cette abstraction est ItemsEnvironment).

45. * </p>

46. * <p>

47. * En particulier en Java, on est souvent amené à utiliser cette technique

48. * avec des enums polymorphiques dont les constantes représentent les

49. * implémentations d'une Stratégie (GOF), ici ClientType.

50. * </p>

51. */

52. //@Entity //Les entités JPA sont un exemple typique d'entités du domaine.

53. public class Bill {

55. //@Field

56. Item billedItem;

58. //@Field, les enums sont persistées sans problème par JPA

59. // (de préference par leur name et non leur ordinal)

60. ClientType billedClientType;

62. //Implémente une logique métier non triviale,

63. //mais pour ce faire à besoin d'un service externe technique/frontière.

64. //Ici la logique métier est localisée dans l'enum "Stratégie" ClientType.

65. public long computeTotalPrice(ItemsEnvironment env) {

66. return billedItem.priceWithoutShipping + this.billedClientType.shippingFeeForWeight(

67. this.billedItem.weight,

68. env

69. );

70. }

71. }

L'entité Bill implémente computeTotalPrice, car cela permet (conformément au DDD et au principe GRASP d'attribution de responsabilité « expert en information ») d'attribuer la responsabilité de produire une information agrégée à l'entité qui contient l'information détaillée. Mais ce calcul nécessite une dépendance envers un service technique (DAO, lookup…). Au lieu de renoncer au DDD et d'implémenter computeTotalPrice sous forme de code procédural dans un service frontière, on introduit une abstraction de ces services. Cette abstraction doit avoir un sens pour le domaine, et doit le moins possible évoquer une préoccupation technique (si possible pas du tout, pour éviter d'introduire une « dépendance croisée conceptuelle »).

Les enums étant supportées au niveau langage, elles sont faciles à sérialiser/persister en BD ou autre. Elles permettent ainsi, à moindres frais, de représenter le lien d'une entité du domaine vers une stratégie. Le besoin d'inversion de dépendance est localisé dans cette enum, dans la dépendance de la méthode shippingFeeForWeight envers un ItemsEnvironment.

ClientType.java

1. package cla.enums.patterns.with.di.model;

3. /**

4. * Comme expliqué dans <tt>Bill</tt>, en Java on utilise souvent l'inversion de

5. * dépendance dans des enums polymorphiques et en particulier celles dont

6. * les constantes représentent les implémentations d'une Stratégie (GOF)

7. * Ici shippingFeeForWeight dépend de l'abstraction <tt>ItemsEnvironment</tt> qui est dans

8. * le package <tt>model</tt>

9. * */

10. public enum ClientType {

12. GOLD {

13. @Override public long feeMultiplier() {

14. return 1;

15. }

16. },

18. SILVER {

19. @Override public long feeMultiplier() {

20. return 2;

21. }

22. },

24. ;

26. public long shippingFeeForWeight(double weight, ItemsEnvironment env) {

27. //C'est ici qu'on a besoin d'un composant "service",

28. // mais on pourrait aussi dépendre d'un Repository, ...

29. //Cette nécessité se manifeste souvent quand on veut faire du domain-driven design.

30. long baseFee = env.fees().baseShippingFee(weight);

31. return baseFee * feeMultiplier();

32. }

34. protected abstract long feeMultiplier();

35. }

L'abstraction de l'environnement/du contexte dans lequel baigne l'entité à l'allure suivante : elle contient typiquement une méthode de service, ou (comme ici) un ou plusieurs getters vers des interfaces de services.

ItemsEnvironment.java

1. package cla.enums.patterns.with.di.model;

4. /**

5. * L'abstraction commune dont dépendent :

6. * <ul>

7. * <li>les entités du domaine et en particulier l'enum <tt>ClientType</tt>

8. * <li>le bean d'implémentation technique du package <tt>services</tt>, <tt>ItemsEnvironmentBean</tt>

9. * </ul>

10. */

11. public interface ItemsEnvironment {

13. /**

14. * Ici l'environnement ne comporte qu'un service technique.

15. * En réalité l'interface environnement pourrait exposer différents types de

16. * composants stateless ou stateful sous une forme abstraite pour la couche métier.

17. * FeeServices représente le frais de port "de base" avant application

18. * d'un multiplicateur spécifique au type de client SILVER/GOLD.

19. */

20. FeeServices fees();

22. /**

23. * L'abstraction d'un service technique (par exemple un WS)

24. */

25. public interface FeeServices {

26. long baseShippingFee(double weight);

27. }

28. }

L'implémentation de l'environnement est contenue dans un package de service/frontière. La dépendance de packages est unidirectionnelle (service/frontière dépend de domaine).

ItemEnvironmentBean.java

1. package cla.enums.patterns.with.di.services;

3. /**

4. * Bean Spring/EE dont ne veulent surtout pas dépendre les entités du domaine.

5. * (elles ne dépendent que de ItemsEnvironment qui fait bien partie du package model)

6. * */

7. public class ItemEnvironmentBean implements cla.enums.patterns.with.di.model.ItemsEnvironment {

9. /**

10. * Ici le côté technique de la classe d'implémentation est illustré par une dépendance

11. * à un service supposément technique, comme un WS remote par ex.

12. * On le met public pour simuler un @Inject de framework à peu de frais depuis ItemsTest#setup().

13. * */

14. //@Inject

15. public FeeServices feeServices;

17. @Override public FeeServices fees() {

18. return feeServices;

19. }

21. }

Le test :

ItemsTest.java

1. package cla.enums.patterns.with.di.model;

3. import cla.enums.patterns.with.di.services.ItemEnvironmentBean;

4. import org.junit.After;

5. import org.junit.Before;

6. import org.junit.Test;

7. import static org.junit.Assert.assertEquals;

9. /**

10. * Tests unitaires de la couche métier.

11. */

12. public class ItemsTest {

14. //@Inject bean technique (injection par Spring Test par ex., on peut facilement utiliser un "fake object"/mock)

15. private ItemEnvironmentBean env;

17. //Le SUT (System Under Test)

18. private Bill bill;

20. @Test public void totalPriceTakesBasePriceAndShippingFeeIntoAccount() {

21. assertEquals(

22. 19.0D, //7 + (3*2)*2

23. bill.computeTotalPrice(this.env),

24. 0.0D //précision de double OK pour les petits entiers

25. );

26. }

28. //---setup/teardown

29. @Before public void setup() {

30. //1. Create bill

31. this.bill = new Bill();

32. bill.billedItem = new Item();

33. bill.billedItem.priceWithoutShipping = 7L;

34. bill.billedItem.weight = 2.0D;

35. bill.billedClientType = ClientType.SILVER;//*2

37. //2. Simule l'injection de dépendance

38. env = new ItemEnvironmentBean();

39. env.feeServices = (double weight) -> 3*Math.round(weight);//3*2=6

40. }

41. @After public void teardown() {

42. this.env = null;

43. this.bill = null;

44. }

45. }

VI - Conclusion et remerciements

En Java, on a la chance que les enums soient de vrais objets, alors autant les intégrer à nos designs. Comme pour beaucoup de patterns (Command par exemple), l'inversion de dépendance permet d'utiliser les enums dans une conception « Domain Driven ». Le code est téléchargeable à l'adresse https://github.com/vandekeiser/javaenums-implpatterns

Cet article a été publié avec l'aimable autorisation de Laurent Claisse. L'article original (Quelques patterns d'implémentation avec les enums java) peut être vu sur le blog/site de Zenika, experts en technologies Open Source et méthodes Agiles.

Nous tenons à remercier f-leb pour sa relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.