Il y a 5 années -

Temps de lecture 1 minute

Screencast Bonus Calculator

On entend souvent dire que l’héritage c’est le mal. Mais quelles sont les justifications à ce type d’assertions ? Pourquoi faut-il favoriser la composition plutôt que l’héritage ? Avec ce screencast vous allez pouvoir observer une application concrète de ce principe. Diego et Sébastian se livrent à un ping pong TDD afin d’aboutir à un code plus maintenable et plus évolutif.

Si vous voulez faire l’exercice vous-même, les sources sont disponibles sur GitHub.

Pour ceux qui se poseraient la question : nous employons parfois le terme de P.O. : il s’agit de l’acronyme de Product Owner et matérialise le rôle du détenteur du produit. Il connait les fonctionnalités de son produit et sait quelles modifications apporter pour augmenter sa valeur.

Publié par Diego Lemos

Diego s’est forgé une solide expérience dans l'écosystème Java. Depuis, longtemps convaincu par l’agilité, Diego a participé à des nombreux projets agiles, d’abord en tant que développeur, puis en tant que scrum master et ensuite coach technique. Diego dispose d’un vaste panel de compétences sur l’ensemble de l’écosystème JVM, et notamment les solutions du monde open-source.
Passionné par l’informatique, il a eu l’occasion de d’intervenir sur des missions techniques très variées, notamment en tant que en tant que développeur frontend et sysadmin. Cela fait de Diego un expert technique full stack.
Il a joué un rôle important dans des projets de grande envergure, en tant que coach technique, notamment autour de la mise en place de pratiques tels que le Continuous Delivery à l’échelle. Aujourd’hui, Diego intervient principalement en tant que formateur, consultant et coach technique sur des sujets tels que le testing, le design du code, le software craftsmanship et le continuous delivery.
Blog personnel : http://diegolemos.net
Twitter : @dlresende.

Publié par Sébastian Le Merdy

Sébastian est entré chez Xebia en 2011 pour mettre en pratique le Software Development Done Right.
Il est passionné par le développement logiciel et les technologies innovantes et le met au service de l'utilisateur final à travers l'agilité dans les projets.
Vous pourrez peut-être le rencontrer lors d'un coding dojo ou une présentation de live coding.

Commentaire

4 réponses pour " Screencast Bonus Calculator "

  1. Publié par , Il y a 5 années

    Je trouve l’exemple mal choisie, la méthodologie et le résultat criticable.
    A la fin le « / 100 » par exemple est toujours dupliqué.
    Ici le calcul de bonus est le même pour tous les employées, seul le pourcentage change et le calcul de bonus n’est pas utilisé ailleurs.
    L’exemple ne montre pas pourquoi favorise la composition par rapport à l’héritage, il montre juste comment mal utilisé l’héritage.
    Je pense que la logique voudrait de faire une classe employée du genre :

    public class Employee {
    private double pourcentageBonus;
    public Employee(String name) {
    this(name, DEFAULT_BONUS);
    }
    public Employee(String name, double percentageBonus) {
    this.name = name;
    this.percentageBonus = percentageBonus;
    }
    public double calculateBonus(double turnover) {
    return turnover * percentageBonus / 100;
    }
    }

    ou encore :

    public class Employee {
    […]
    protected abstract double getPercentageBonus();

    public double calculateBonus(double turnover) {
    return turnover * getPercentageBonus() / 100;
    }
    }

    Et d’avoir quelquel part 3 constantes définies pour les bonus min, medium et max.

  2. Publié par , Il y a 5 années

    Ce qu’on veux montrer avec cette vidéo, c’est qu’on a découplé le calcul du bonus de la classe Employee elle même car la notion d’Employee n’est pas liée à celle de BonusCalculator. Pour justifier pleinement la composition, il manque sans doute des formules de calcul différentes.

    D’un point de vue responsabilité dans la solution que tu proposes, on est obligé d’instancier des Employee pour vérifier le calcul des bonus. Dans la solution de la vidéo, on vérifie ces calculs indépendamment.

  3. Publié par , Il y a 5 années

    Découplé le calcul du bonus de la classe Employee n’est pas une mauvaise chose mais ce n’est pas le premier problème qui me vient à l’esprit en voyant les classes de départ, surtout que ce calcul de bonus n’a aucune complexité et qu’il n’est indiqué comme étant employé que dans la classe Employee.

    Votre énoncé laisse entendre que vous opposez héritage et composition, les deux sont complémentaires.
    Ici en fait même en découplant le calcul de la classe employée il serait logique d’avoir de l’héritage sur la classe Bonus, puisque la formule de calcul du bonus est unique.
    Je trouve qu’il est nuisible d’avoir des classes différentes dont la seul différence est la valeur d’une constante, comme c’est le cas pour les bonus calculator. C’est autant de risque d’erreur et niveau test vous avez autant de classe de calcul de bonus à tester qu’il y aura de catégorie de bonus. (La il n’y en a que trois mais c’est le genre de chose qui peut facilement se multiplier.)

    Si j’avais voulu découplé le calcul du bonus comme dans votre exemple et distinguer le calcul du bonus MAX, MIN et MEDIUM, je pense que je serai parti sur une solution du genre :
    public class FixedPercentageBonusCalculator implements BonusCalculator {
    private static final double BONUS_MIN_PERCENTAGE = 0.01;
    private static final double BONUS_MEDIUM_PERCENTAGE = 0.02;
    private static final double BONUS_MAX_PERCENTAGE = 0.03;
    public static final Bonus BONUS_MIN_CALCULATOR = new BonusCalculator(BONUS_MIN_PERCENTAGE);
    public static final Bonus BONUS_MEDIUM_CALCULATOR = new BonusCalculator(BONUS_MEDIUM_PERCENTAGE);
    public static final Bonus BONUS_MAX_CALCULATOR = new BonusCalculator(BONUS_MAX_PERCENTAGE);
    private double bonusPercentage;
    public BonusCalculator(int bonusPercentage) {
    this.bonusPercentage = bonusPercentage;
    }
    public double calculateBonus(double turnover) {
    return turnover * bonusPercentage;
    }
    }
    J’aurais mis un attribut privé final pour le bonus Calculator dans Employee avec un constructeur qui le prend en paramètre pour que les classes filles puissent en définir un autre.
    Mais bon il y a toujours 100 000 façons de coder la même chose, chacun voit ces besoins.

  4. Publié par , Il y a 5 années

    Oups, quelques erreurs à corriger, avec :

    public static final BonusCalculator BONUS_MIN_CALCULATOR = new FixedPercentageBonusCalculator(BONUS_MIN_PERCENTAGE);
    public static final BonusCalculator BONUS_MEDIUM_CALCULATOR = new FixedPercentageBonusCalculator(BONUS_MEDIUM_PERCENTAGE);
    public static final BonusCalculator BONUS_MAX_CALCULATOR = new FixedPercentageBonusCalculator(BONUS_MAX_PERCENTAGE);

    ça serait mieux (un ide c’est quand même plus pratique pour développer qu’un text-area ^^).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.