Howto de conception pour l'extension

Il y a un Checkstyle règle DesignForExtension. Il dit: si vous avez un public/protected méthode qui n'est pas abstrait, ni définitive, ni vide, c'est pas "conçu pour l'extension". Lire la la description de cette règle sur la page Checkstyle de la justification.

Imaginez ce cas. J'ai une classe abstraite qui définit certains champs et une méthode de validation de ces champs:

public abstract class Plant {
    private String roots;
    private String trunk;

    //setters go here

    protected void validate() {
        if (roots == null) throw new IllegalArgumentException("No roots!");
        if (trunk == null) throw new IllegalArgumentException("No trunk!");
    }

    public abstract void grow();
}

J'ai aussi une sous-classe de la Plante:

public class Tree extends Plant {
    private List<String> leaves;

    //setters go here

    @Overrides
    protected void validate() {
        super.validate();
        if (leaves == null) throw new IllegalArgumentException("No leaves!");
    }

    public void grow() {
        validate();
        //grow process
    }
}

À la suite de la Checkstyle règle de la Plante.valider() la méthode n'est pas conçu pour l'extension. Mais comment la conception de l'extension dans ce cas?

  • Vous ne devriez pas jeter une IllegalArgumentException dans une méthode qui ne prend pas d'arguments...
  • Faisons semblant de croire que c'est l'exception IllegalStateException pour le bien de la "argument" 🙂
InformationsquelleAutor Eduard Wirch | 2009-03-19