Je peux me mettre en premier, même après si je veux

Nous avons une interface appelée Paiement contenant une méthode de paiement .

Et une classe concrète DefaultPayment pour implémenter la méthode, la méthode prend le prix en argument pour faire la logique de paiement.

public interface Payment {
    void pay(BigDecimal price);
}
public class DefaultPayment implements Payment {
    @Override
    public void pay(BigDecimal price) {
        System.out.println("Payed: " + price);
    }
}

public class Client {
    public static void main(String[] args) {
        Payment defaultPayment = new DefaultPayment();
        defaultPayment.pay(BigDecimal.valueOf(100));
    }
}

Disons qu'il y a une taxe sur un produit que je veux payer, que puis-je faire ?

Nous pouvons profiter de notre conception, nous avons conçu pour une interface et non pour une implémentation.

Ainsi, nous pouvons créer une classe pour Payment et la laisser être un type de Payment et en même temps conserver le Payment comme propriété, et il pourrait prendre le paiement en utilisant son constructeur, et nous appellerons cette classe TaxPaymentDecorator .

public class TaxPaymentDecorator implements Payment {
    private Payment payment;
    private BigDecimal tax = BigDecimal.ZERO;

    public TaxPaymentDecorator(Payment payment) {
        this.payment = payment;
    }

    @Override
    public void pay(BigDecimal price) {
        price = price.add(this.tax);
        payment.pay(price);
    }

    public BigDecimal getTax() {
        return tax;
    }

    public void setTax(BigDecimal tax) {
        this.tax = tax;
    }
}

Et le client pourrait utiliser le TaxPaymentDecorator comme suit :

public class Client {
    public static void main(String[] args) {
        TaxPaymentDecorator taxPaymentDecorator = new TaxPaymentDecorator(new DefaultPayment());
        taxPaymentDecorator.setTax(BigDecimal.valueOf(50));
        taxPaymentDecorator.pay(BigDecimal.valueOf(100));
    }
}

public class DiscountPaymentDecorator implements Payment {
    private Payment payment;
    private BigDecimal discount = BigDecimal.ZERO;

    public DiscountPaymentDecorator(Payment payment) {
        this.payment = payment;
    }

    @Override
    public void pay(BigDecimal price) {
        price = price.subtract(discount);
        payment.pay(price);
    }

    public BigDecimal getDiscount() {
        return discount;
    }

    public void setDiscount(BigDecimal discount) {
        this.discount = discount;
    }
}

public class Client {
    public static void main(String[] args) {
        TaxPaymentDecorator taxPaymentDecorator = new TaxPaymentDecorator(new DefaultPayment());
        taxPaymentDecorator.setTax(BigDecimal.valueOf(50));
        DiscountPaymentDecorator discountPaymentDecorator = new DiscountPaymentDecorator(taxPaymentDecorator);
        discountPaymentDecorator.setDiscount(BigDecimal.valueOf(10));
        discountPaymentDecorator.pay(BigDecimal.valueOf(100));
    }
}

Diagramme UML

Principes de conception

Je vais aborder trois principes de conception ici :

1. Conception pour une interface non destinée à l'implémentation : comme vous le voyez, l'utilisation de l' interface de paiement nous a aidés à utiliser la puissance de la POO en ajoutant dynamiquement un comportement au moment de l'exécution sans aucune modification pour l'ancienne implémentation.
2. Rendez votre conception ouverte pour extension fermée pour modification : ce point est lié au précédent, notre ancienne implémentation ne nous obligeait à aucune modification, mais nous avons étendu l'ancienne implémentation pour ajouter de nouveaux comportements, et je veux dire ici en utilisant l'interface à la place de la conception à la mise en œuvre.
3. Préférez la composition à l'héritage : le décorateur utilise la composition ici au lieu d'essayer d'utiliser l'héritage, en général l'utilisation de l'héritage pourrait causer des problèmes en augmentant le couplage, et nous pourrions en discuter dans un blog séparé.

Attachez dynamiquement des responsabilités supplémentaires à un objet. Les décorateurs offrent une alternative flexible aux sous-classes pour étendre les fonctionnalités.

Dans notre exemple, nous avons attaché dynamiquement deux responsabilités au moment de l'exécution, nous avons ajouté la taxe au prix et soustrait la remise du prix, nous n'avons pas fait de sous-classement pour le DefaultPayment, nous avons utilisé la puissance de la POO pour ajouter nos comportements de manière flexible, et c'est le motif Decorator .