Hay una regla CheckstyleDesignForExtension. Dice: si tiene un método público/protegido que no es abstracto ni definitivo ni está vacío, no está "diseñado para la extensión". Lea el description for this rule on the Checkstyle page para la justificación.Cómo diseñar para la extensión
Imagine this case. Tengo una clase abstracta que define algunos campos y un método de validación para los campos:
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();
}
también tengo una subclase de la planta:
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
}
}
Tras la Checkstyle gobernar el Plant.validate (método) no está diseñado para la extensión. ¿Pero cómo diseño la extensión en este caso?
No debe tirar una IllegalArgumentException en un método que no tiene argumentos. .. – markt
@markt Imaginemos que es IllegalStateException por el bien del "argumento" :) –