[JAVA] [Reading Memo] Refactoring-Typecode replacement (pour les types de code qui affectent le comportement) -2

Modèle d'état?

https://qiita.com/takutotacos/items/654e204d618d2059de7f Le but est de faire quelque chose de similaire.

Je veux faire ↑, mais utiliser ce modèle lorsque le code de type change pendant la vie de l'objet. C'est une «sous-classification» qui peut gérer les modifications du code de type.

Comment fais-tu ça?

Changer avant.java

class Employee {
    static final int ENGINEER = 0;
    static final int SALESMAN = 1;
    static final int MANAGER = 2;

    private int type;

    public Employee(int type) {
        this.type = type;
    }

    int payAmount() {
        switch (type) {
            case ENGINEER: return monthlySalary;
            case SALESMAN: return monthlySalary + commission;
            case MANAGER : return monthlySalary + bonus;

        }
    }
}

Je veux me débarrasser de l'instruction switch ci-dessus. Pour cela, implémentez ce qui suit.

Après le changement.java

class Employee {
    private EmployeeType type;

    int getType() {
        return type.getType();
    }

    void setType(int type) {
        this.type = EmployeeType.newType(type);
    }
}

abstract class EmployeeType {
    public static final int ENGINEER = 0;
    public static final int SALESMAN = 1;
    public static final int MANAGER = 2;

    static EmployeeType newType(int code) {
        switch (code) {
            case EmployeeType.ENGINEER: return new Engineer();
            case EmployeeType.SALESMAN: return new Salesman();
            case EmployeeType.MANAGER : return new Manager();
            default: throw new IllegalArgumentException("Code d'employé illégal");
        }
    }

    abstract int getType();
}

public class Engineer extends EmployeeType {
    @Override
    int getType() {
        return EmployeeType.ENGINEER;
    }
}

class Salesman extends EmployeeType {
    @Override
    int getType() {
        return EmployeeType.SALESMAN;
    }
}

class Manager extends EmployeeType {
    @Override
    int getType() {
        return EmployeeType.MANAGER;
    }
}

Après cela, si la logique de calcul du salaire est implémentée dans chaque sous-classe, il n'y a pas de branchement conditionnel à partir de la classe client sauf pour la création d'objet. Dans ce cas, il semble que vous n'oublierez pas d'implémenter la logique même si vous augmentez les types de sous-classes. Même si vous oubliez d'ajouter une sous-classe à l'instruction switch lors de la création d'un objet, cela se terminera par une erreur, ce qui en fait un programme facile à déboguer qui permet de reconnaître facilement l'implémentation oubliée.