article.txt

Quelques patterns d'implémentation avec les enums java

Bien que les enums soient apparues en java 5, elles sont parfois sous-utilisées. Voyons quelques patterns d'implémentation.

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 du C++.
Les enums java sont l'aboutissement d'un processus différent: l'incarnation d'un pattern d'implémentation (les type-safe enums de Effective java 1ere edition) dans une feature du langage (il s'agit d'un processus classique d'évolution d'un langage).

Contrairement aux enums value types, 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 compil ni au runtime).
-Elles sont polymorphiques: chaque valeur peut implémenter différement:
	-Une méthode d'une interface implémentée par son type
	-Une méthode abstraite définie par son type

1/a/ L'enum singleton
Cf. Effective java, le singleton naïf:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/**
 * L'implémentation naïve du singleton offre moins de garanties que l'enum,
 * surtout pour un type sérialisable.
 */
public class NaiveSingleton implements Serializable {
	
	private NaiveSingleton() {}
	
	public static final NaiveSingleton instance = new NaiveSingleton(); 
	
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

maintient la garantie d'instance unique en empêchant l'instanciation par constructeur depuis une autre classe.
Cependant, il n'est pas préservé contre les instanciations par les mécanismes extra-linguistiques: invocation du constructeur par réflexion, copie par sérialisation (s'il implémente Serializable), clone (peu vraisemblable certes).

Les enums sont un singleton idéal car le code générée par javac interdit ces tentatives:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/**
 * Un singleton stateless. 
 * Java Puzzlers suggère d'utiliser une enum pour être sûr à moindre frais
 * que cette enum en est vraiment une.
 */
public enum Factory {
	
	instance;

	public Object create() {
		return new Object();
	}
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


1/b/ L'enum singleton stateful
Ce pattern est parfois découragé dans la littérature mais sans trop dire pourquoi?
Effective Java encourage l'implémentation des enums par singleton, mais sans mentionner la distinction stateless/stateful.
Avez-vous une idée sur la question?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/**
 * Un singleton stateful.
 * Ce pattern est parfois découragé dans la littérature mais sans trop dire pourquoi?
 * Effective Java et Java puzzlers encouragent l'implémentation du singleton par enum, 
 * mais sans mentionner la distinction stateless/stateful.
 */
public enum Repository {
	
	instance;

	private final ConcurrentMap<String, Object> repo = new ConcurrentHashMap<>();
	
	public Object forKey(String key) {
		Object obj = new Object();
		repo.putIfAbsent(key, obj);
		return obj;
	}
	
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2/ L'enum "static class"

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 "coin 2" via un changement de javac,
mais les concepteurs de Java doivent avoir peur d'ajouter à la confusion qui entoure déjà les nested classes statiques VS inner classes VS static class en C#).  
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
public enum Maths {
	
	;//Une enum commence toujours par la déclaration de ses instances (les "enum constants");
	 //ici il n'y en a aucune mais le bloc est quand même obligatoire.
	
	public static double PI = 4*java.lang.Math.atan(1.0D);//tan(pi/4)=1 cf. le cercle trigonométrique
	
	public static double cos(double radians) {
		return 0D;//TODO
	} 
	
	//Impossible à appeler (à moins que??)
	public double toto() {return 999D;}
}

public class MathsTest {
	/**
	 * <p>Quand un test passe au vert alors qu'on n'a encore rien fait c'est que le test ne teste rien.</p>
	 * <p>C'est pour ça qu'il faut d'abord obtenir le rouge avant d'implémenter.</p>
	 * <p>Ici le test est trompeur, voyez-vous pourquoi?</p>
	 */
	@Test public void cosinusAngleDroitEgaleZero() {
		assertEquals(
				0D, 
				Maths.cos(Maths.PI/2),
				0D
		);
	}
	
	/**
	 * Pas possible d'invoquer la méthode non-statique <code>toto()</code>
	 * (c'est difficile parce que les enums sont bien blindées).
	 */
	@Ignore
	@Test public void impossible() {
//		assertEquals(
//				999D, 
//				new Maths().toto(),
//				0D
//		);
	}
}

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


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: 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
private Math(){throw new UnsupportedOperationException();}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
, qui permet de rentrer dans le constructeur (même si c'est pour crasher tt de suite), et qui est un peu plus verbeux.


3/ Enums polymorphiques
Rentrons dans le vif du sujet avec ce pattern extrêmement puissant. 

a/ Variation: implémentation complète

Dans cette variation, 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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
package cla.enums.patterns.strategy.complete;

public interface BinaryOperation {
	
	double apply(double d1, double d2);
	
	public enum ArithmeticOperation implements BinaryOperation {
		
		PLUS("+") {
			@Override public double apply(double d1, double d2) {
				return d1 + d2;
			}
		},
		
		MINUS("-") {
			@Override public double apply(double d1, double d2) {
				return d1 - d2;
			}
		},
		
		TIMES("*") {
			@Override public double apply(double d1, double d2) {
				return d1 * d2;
			}
		},
		
		DIVIDED_BY("/") {
			@Override public double apply(double d1, double d2) {
				return d1 / d2;
			}
		},
		
		;
		
		private final String symbol;
		private ArithmeticOperation (String symbol) {this.symbol = symbol;}
		
		@Override public String toString() {
			return this.symbol;
		}
	}

}

public class BinaryOperationTest {

	@Test public void plus() {
		assertEquals(
				3D, 
				PLUS.apply(1D, 2D),
				0D
		);
	}

	@Test public void minus() {
		assertEquals(
				-1D, 
				MINUS.apply(1D, 2D),
				0D
		);
	}

	@Test public void times() {
		assertEquals(
				6D, 
				TIMES.apply(2D, 3D),
				0D
		);
	}

	@Test public void dividedBy() {
		assertEquals(
				2D, 
				DIVIDED_BY.apply(6D, 3D),
				0D
		);
	}

	@Test public void printPlus() {
		assertEquals(
				"+", 
				PLUS.toString()
		);
	}

	@Test public void printMinus() {
		assertEquals(
				"-", 
				MINUS.toString()
		);
	}

	@Test public void printTimes() {
		assertEquals(
				"*", 
				TIMES.toString()
		);
	}

	@Test public void printDividedBy() {
		assertEquals(
				"/", 
				DIVIDED_BY.toString()
		);
	}
}	
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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).

Etant données les deux classes:

1: métier
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/**
 * Une entité du domaine
 */
public class Record {
	
	public boolean  logicallyDeleted; 
	
	//Example peu réaliste mais simple, car ce n'est pas le sujet; 
	//dans la réalité la suppression physique ne serait sûrement pas implémentée par un flag.
	public boolean physicallyDeleted;
	
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

et 2: d'infrastructure:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
public interface RecordEnv {

	public interface PhysicalDeleter {
		void deletePhysically(Record r);
	}	
	public interface LogicalDeleter {
		void deleteLogically(Record r);
	}
	
	default PhysicalDeleter physicalDeleter() {
		return (Record r) -> r.physicallyDeleted=true;
	}
	default LogicalDeleter logicalDeleter() {
		return (Record r) -> r.logicallyDeleted=true;
	}
	
} 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3: Dans ce contexte, on peut avantageusement représenter certaines stratégies d'effacement d'une ligne par des enums:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
public interface RecordDeletionStrategy {
	
	/**
	 * L'unique méthode, ce qui est le plus fréquent pour une stratégie
	 */
	void deleteRecord(Record r, RecordEnvironment env);
	
	/**
	 * Les "enums dégénérées" sont une sous-variante du pattern,
	 * dans laquelle les enum constants représentent des implémentations non-opérationnelles,
	 * utilisables comme Null Object (Fowler, POEA) ou comme fake object de test.
	 * Quelques exemples de ces fakes objects:
	 */
	public enum DegenerateImpls implements RecordDeletionStrategy {
		
		/**
		 * Null object/dummy. 
		 */
		NOOP {
			@Override public void deleteRecord(Record r, RecordEnvironment env) {
				;
			}
		},

		/**
		 * Implémentation par défaut d'une opération optionnelle (cf. le Collections framework du JDK).
		 */
		UNSUPPORTIVE {
			@Override public void deleteRecord(Record r, RecordEnvironment env) {
				throw new UnsupportedOperationException();
			}
		},
		
		/**
		 * Simule un problème, pour les tests de gestion d'erreur par exemple.
		 */
		DEFECTIVE {
			@Override public void deleteRecord(Record r, RecordEnvironment env) {
				throw new RuntimeException();
			}
		},
		
		;
	}
	
	/**
	 * Les "implémentation connues" sont une autre sous-variante du pattern,
	 * où les enum constants représentent des implémentations opérationnelles fournies par l'API,
	 * mais qui peuvent être complétées par des implémentations de l'application.
	 */
	public enum WellKnownImpls implements RecordDeletionStrategy {
		
		/**
		 * Fait un delete en BD (par ex.)
		 */
		PHYSICAL_DELETION {
			@Override public void deleteRecord(Record r, RecordEnvironment env) {
				env.physicalDeleter().deletePhysically(r);
			}
		},
		
		/**
		 * Met le flag 'DELETED' à true 
		 */
		LOGICAL_DELETION {
			@Override public void deleteRecord(Record r, RecordEnvironment env) {
				env.logicalDeleter().deleteLogically(r);
			}
		},

		;
	}
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

c/ Variation: enums du domaine avec inversion de dépendance

DI veut dire "dependency <i>injection</i>" mais est aussi parfois utilisé comme abbréviation de "dependency <i>inversion</i>"
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.
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 plus concret est d'éviter les dépendances croisées entre les packages métier et les packages techniques ou de démarcation transactionnelle (en Adam Bien, entre "entity" et ("boundary" ou "control") du pattern ECB Entity/Control/Boundary)

En effet, la dépendance des packages métiers vers les packages techniques/frontière qu'il induit est a priori un obstacle au Design Driven Model 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 dans la couche métier permet de contourner cette obstacle en introduisant dans la couche métier une abstraction, significative du point de vue de cette couche, des services techniques/de frontière.
(Une solution alternative pour éviter la pollution des préoccupations fonctionnelles par les préoccupations techniques est l'AOP)

Concrètement, le package métier com.toto.modele contient XXXEntity et XXXHelper/XXXServices/XXXEnvironment (où XXX représente des trains, des entrepôts de carottes, ...),
et le package technique com.toto.services contient XXXServicesImpl (par ex. un bean Spring transactionnel).

1: Prenons le cas de 2 entités du modèle du domaine:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
package cla.enums.patterns.with.di.model;
/**
 * Une entité du domaine.
 * Ici son seul intérêt dans l'exemple est d'être agrégée par <tt>Bill</tt>,
 * qui lui colocalise état et logique métier. 
 */
//@Entity
public class Item {

	public long priceWithoutShipping;
	
	public double weight;

}

/**
 * Une entité du domaine.
 * <p>
 * Elle colocalise état et logique métier,
 * contrairement à l'antipattern fréquent des "entités étiques" (squelettiques).
 * Le livre "domain-driven design" décrit cet l'antipattern dans lequel
 * les entités ressemblent à des structs sans logique métier,
 * qui est alors principalement contenue dans des "transaction scripts"
 * (typiquement de longues méthodes procédurales dans un composant "frontière",
 * comme un web service, un EJB remote, un bean Spring transactionnel, ...)
 * </p>
 * <p>
 * L'inconvénient principal de cet antipattern est que comme la couche objet n'a pas d'épaisseur,
 * on perd tous les avantages de la modélisation objet.
 * </p>
 * <p>
 * Le livre explique en outre que la fréquence de cet antipattern s'explique 
 * par une difficulté technique: la plupart du temps, pour réaliser une logique métier non-triviale,
 * les objets du domaine auraient besoin de dépendre de composants techniques ou frontière
 * (frontière au sens de boundary du pattern EE entity/control/boundary).
 * Ceci serait problématique, car d'autre part les composants frontière dépendent toujours 
 * des entités du domaine; on aboutirait alors à une dépendance croisée entre les packages
 * <tt>cla.enums.patterns.with.polymorphism.and.di.model</tt> et 
 * <tt>cla.enums.patterns.with.polymorphism.and.di.services</tt>.
 * La façon la plus simple mais pas la meilleure de s'affranchir de cette difficulté
 * est de mettre toute la logique métier dans les composants frontière,
 * et on arrive alors à l'antipattern décrit.     
 * </p>
 * <p>
 * Une solution plus satisfaisante est d'utiliser l'inversion de dépendance, 
 * qui consiste à remplacer la dépendance entre deux packages par une dépendance
 * des deux envers une abstraction commune, contenue dans le package métier
 * (ici cette abstraction est ItemsEnvironment).
 * </p>
 * <p>
 * En particulier en Java, on est souvent amené à utiliser cette technique 
 * avec des enums polymorphiques dont les constantes représentent les 
 * implémentations d'une Stratégie (GOF), ici ClientType.  
 * </p>       
 */
//@Entity //Les entités JPA sont un exemple typique d'entités du domaine. 
public class Bill {
	
	//@Field
	Item billedItem;
	
	//@Field, les enums sont persistées sans problème par JPA 
	// (de prference par leur name et non leur ordinal)
	ClientType billedClientType;
	
	//Implémente une logique métier non triviale,
	// mais pour ce faire à besoin d'un service externe technique/frontière.
	// Ici la logique métier est localisée dans l'enum "Stratégie" ClientType.
	//(Rien à voir, mais on ne fait jamais de calcul exacts (monétaires ou autre) avec des types binaires,
	// ici on représente la quantité monétaire en centimes (de quelle monnaie??) car ce n'est pas le sujet, 
	// mais une solution plus réaliste est d'utiliser le pattern Quantité)
	public long computeTotalPrice(ItemsEnvironment env) {
		return  billedItem.priceWithoutShipping + this.billedClientType.shippingFeeForWeight(
			this.billedItem.weight, 
			env
		);
	}
}

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

L'entité Bill implémente computeTotalPrice, car cela permet (conformément au DDD et au principe 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")

2: Les enums étant supportées au niveau langage, elles sont faciles à sérialiser/persister en BD ou autre. 
On peut donc représenter à moindre frais le lien d'une entité du domaine vers une stratégie.
Le besoin d'inversion de dépendance est localisé dans cette enum.

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

/**
 * Comme expliqué dans <tt>Bill</tt>, en Java on utilise souvent l'inversion de 
 * dépendance dans des enums polymorphiques et en particulier celles dont 
 * les constantes représentent les implémentations d'une Stratégie (GOF)
 * Ici shippingFeeForWeight dépend de l'abstraction <tt>ItemsEnvironment</tt> qui est dans 
 * le package <tt>model</tt>   
 * */
public enum ClientType {

	GOLD {
		@Override public long feeMultiplier() {
			return 1;
		}
	},
	
	SILVER {
		@Override public long feeMultiplier() {
			return 2;
		}
	},
	
	;
	
	public long shippingFeeForWeight(double weight, ItemsEnvironment env) {
		//C'est ici qu'on a besoin d'un composant "service", 
		// mais on pourrait aussi dépendre d'un Repository, ...
		//Cette nécessité se manifeste souvent quand on veut faire du domain-driven design.
		long baseFee = env.fees().baseShippingFee(weight);
		return baseFee * feeMultiplier();
	}

	protected abstract long feeMultiplier();
}

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3: 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/plusieurs getters d'interfaces de services.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
package cla.enums.patterns.with.di.model;


/**
 * L'abstraction commune dont dépendent: 
 * <ul>
 * <li>les entités du domaine et en particulier l'enum <tt>ClientType</tt>
 * <li>le bean d'implémentation technique du package <tt>services</tt>, <tt>ItemsEnvironmentBean</tt>
 * </ul>
 */
public interface ItemsEnvironment {

	/**
	 * Ici l'environnement ne comporte qu'1 service technique. 
	 * En réalité l'interface environnement pourrait exposer différents types de 
	 * composants stateless ou stateful sous une forme abstraite pour la couche métier.
	 * FeeServices représente le frais de port "de base" avant application 
	 * d'un multiplicateur spécifique au type de client SILVER/GOLD.
	 */
	FeeServices fees();

	/**
	 * L'abstraction d'un service technique (par exemple un WS)
	 */
	public interface FeeServices {
		long baseShippingFee(double weight);
	}
}

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



4: L'implémentation de l'environnement est contenue dans un package de service/frontière. La dépendance de packages est monodirectionnelle (service/frontière dépend de domaine) 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
package cla.enums.patterns.with.di.services;

/**
 * Bean Spring/EE dont ne veulent surtout pas dépendre les entités du domaine.
 * Elles ne dépendent que de ItemsEnvironment qui fait bien partie du package model.
 * */
public class ItemEnvironmentBean implements cla.enums.patterns.with.di.model.ItemsEnvironment {

	/**
	 * Ici le côté technique de la classe d'implémentation est illustré par une dépendance 
	 * à un service supposément technique, comme un WS remote par ex. 
	 * On le met public pour simuler un @Inject de framework à peu de frais depuis ItemsTest#setup().  
	 * */
	//@Inject
	public FeeServices feeServices;
	
	@Override public FeeServices fees() {
		return feeServices;
	}
	
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


5: Le test
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
package cla.enums.patterns.with.di.model;

import cla.enums.patterns.with.di.services.ItemEnvironmentBean;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.assertEquals;

/**
 * Tests unitaires de la couche métier.
 */
public class ItemsTest {

	//@Inject bean technique 
	private ItemEnvironmentBean env;
	
	//Le SUT
	private Bill bill;
	
	@Test public void totalPriceTakesBasePriceAndShippingFeeIntoAccount() {
		assertEquals(
			19.0D, //7 + (3*2)*2 
			bill.computeTotalPrice(this.env),
			0.0D //précision OK pour les petits entiers
		);
	}

	//---setup/teardown
	@Before public void setup() {
		//1. Create bill
		this.bill = new Bill();
		bill.billedItem = new Item();
		bill.billedItem.priceWithoutShipping = 7L;
		bill.billedItem.weight = 2.0D;
		bill.billedClientType = ClientType.SILVER;//*2
		
		//2. Simule l'injection de dépendance
        env = new ItemEnvironmentBean();
		env.feeServices = (double weight) -> 3*Math.round(weight);//3*2=6
	}
	@After public void teardown() {
        this.env = null;
        this.bill = null;
	}
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Le code est téléchargeable à l'adresse...