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

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()
        );
    }
}

/**
 * Une entité du domaine
 */
public class Record {
 
    public boolean  logicallyDeleted; 
 
    //Exemple peu réaliste mais simple ; 
    //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.
    public boolean physicallyDeleted;
 
}

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;
    }
 
}

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);
            }
        },
 
        ;
    }
}

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>. 
 */
//@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 antipattern dans lequel
 * les entités ressemblent à des structs sans logique métier,
 * laquelle 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).
 * C'est là que réside la difficulté, 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 (des transaction scripts de 300 lignes).     
 * </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 préference 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.
    public long computeTotalPrice(ItemsEnvironment env) {
        return billedItem.priceWithoutShipping + this.billedClientType.shippingFeeForWeight(
            this.billedItem.weight, 
            env
        );
    }
}

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();
}

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'un 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);
    }
}

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;
    }
 
}

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 (injection par Spring Test par ex., on peut facilement utiliser un "fake object"/mock)
    private ItemEnvironmentBean env;
 
    //Le SUT (System Under Test)
    private Bill bill;
 
    @Test public void totalPriceTakesBasePriceAndShippingFeeIntoAccount() {
        assertEquals(
            19.0D, //7 + (3*2)*2 
            bill.computeTotalPrice(this.env),
            0.0D //précision de double 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;
    }
}