Description

Nothing wrong could be with founded classes. This check makes sense only for library projects (not application projects) which care of ideal OOP-design to make sure that class works in all cases even misusage. Even in library projects this check most likely will find classes that are designed for extension by somebody. User needs to use suppressions extensively to got a benefit from this check, and keep in suppressions all confirmed/known classes that are deigned for inheritance intentionally to let the check catch only new classes, and bring this to team/user attention.

ATTENTION: Only user can decide whether a class is designed for extension or not. The check just shows all classes which are possibly designed for extension. If smth inappropriate is found please use suppression.

ATTENTION: If the method which can be overridden in a subclass has a javadoc comment (a good practice is to explain its self-use of overridable methods) the check will not rise a violation. The violation can also be skipped if the method which can be overridden in a subclass has one or more annotations that are specified in ignoredAnnotations option. Note, that by default @Override annotation is not included in the ignoredAnnotations set as in a subclass the method which has the annotation can also be overridden in its subclass.

Problem is described at "Effective Java, 2nd Edition by Joshua Bloch" book, chapter "Item 17: Design and document for inheritance or else prohibit it".

Some quotes from book:

The class must document its self-use of overridable methods. By convention, a method that invokes overridable methods contains a description of these invocations at the end of its documentation comment. The description begins with the phrase “This implementation.”

The best solution to this problem is to prohibit subclassing in classes that are not designed and documented to be safely subclassed.

If a concrete class does not implement a standard interface, then you may inconvenience some programmers by prohibiting inheritance. If you feel that you must allow inheritance from such a class, one reasonable approach is to ensure that the class never invokes any of its overridable methods and to document this fact. In other words, eliminate the class’s self-use of overridable methods entirely. In doing so, you’ll create a class that is reasonably safe to subclass. Overriding a method will never affect the behavior of any other method.

The check finds classes that have overridable methods (public or protected methods that are non-static, not-final, non-abstract) and have non-empty implementation.

Rationale: This library design style protects superclasses against being broken by subclasses. The downside is that subclasses are limited in their flexibility, in particular they cannot prevent execution of code in the superclass, but that also means that subclasses cannot corrupt the state of the superclass by forgetting to call the superclass's method.

More specifically, it enforces a programming style where superclasses provide empty "hooks" that can be implemented by subclasses.

Example of code that cause violation as it is designed for extension:

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

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

  public abstract void grow();
}

public class Tree extends Plant {
  private List leaves;

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

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

Example of code without violation:

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

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

  protected void validateEx() { }

  public abstract void grow();
}
        

Properties

Examples

To configure the check:

<module name="Checker">
  <module name="TreeWalker">
    <module name="DesignForExtension"/>
  </module>
</module>
        

Example:

public abstract class Example1 {
  private int bar;

  public int m1() {return 2;}  // violation

  public int m2() {return 8;}  // violation

  private void m3() {m4();}  // OK. Private method.

  protected void m4() { }  // OK. No implementation.

  public abstract void m5();  // OK. Abstract method.

  /**
   * This implementation ...
   @return some int value.
   */
  public int m6() {return 1;}  // OK. Have javadoc on overridable method.

  /**
   * Some comments ...
   */
  public int m7() {return 1;}  // OK. Have javadoc on overridable method.

  /**
   * This
   * implementation ...
   */
  public int m8() {return 2;}  // OK. Have javadoc on overridable method.

  @Override                   // violation
  public String toString() {
    return "";
  }
}
        

To configure the check to allow methods which have @Override annotations to be designed for extension.

<module name="Checker">
  <module name="TreeWalker">
    <module name="DesignForExtension">
      <property name="ignoredAnnotations" value="Override"/>
    </module>
  </module>
</module>
        

Example:

public abstract class Example2 {
  private int bar;

  public int m1() {return 2;}  // violation

  public int m2() {return 8;}  // violation

  private void m3() {m4();}  // OK. Private method.

  protected void m4() { }  // OK. No implementation.

  public abstract void m5();  // OK. Abstract method.

  /**
   * This implementation ...
   @return some int value.
   */
  public int m6() {return 1;}  // OK. Have javadoc on overridable method.

  /**
   * Some comments ...
   */
  public int m7() {return 1;}  // OK. Have javadoc on overridable method.

  /**
   * This
   * implementation ...
   */
  public int m8() {return 2;}  // OK. Have javadoc on overridable method.

  @Override
  public String toString() {
    return "";
  }
}
        

To configure the check to allow methods which contain a specified comment text pattern in their javadoc to be designed for extension.

<module name="Checker">
  <module name="TreeWalker">
    <module name="DesignForExtension">
      <property name="requiredJavadocPhrase" value="This implementation"/>
    </module>
  </module>
</module>
        

Example:

public abstract class Example3 {
  private int bar;

  public int m1() {return 2;}  // violation

  public int m2() {return 8;}  // violation

  private void m3() {m4();}  // OK. Private method.

  protected void m4() { }  // OK. No implementation.

  public abstract void m5();  // OK. Abstract method.

  /**
   * This implementation ...
   @return some int value.
   */
  public int m6() {return 1;}  // OK. Have required javadoc.

  /**
   * Some comments ...
   */
  public int m7() {return 1;}  // violation

  /**
   * This
   * implementation ...
   */
  public int m8() {return 2;}  // violation

  @Override                    // violation
  public String toString() {
    return "";
  }
}
        

To configure the check to allow methods which contain a specified comment text pattern in their javadoc which can span multiple lines to be designed for extension.

<module name="Checker">
  <module name="TreeWalker">
    <module name="DesignForExtension">
      <property name="requiredJavadocPhrase"
        value="This[\s\S]*implementation"/>
    </module>
  </module>
</module>
        

Example:

public abstract class Example4 {
  private int bar;

  public int m1() {return 2;}  // violation

  public int m2() {return 8;}  // violation

  private void m3() {m4();}

  protected void m4() { }  // OK. No implementation.

  public abstract void m5();  // OK. Abstract method.

  /**
   * This implementation ...
   @return some int value.
   */
  public int m6() {return 1;}  // OK. Have required javadoc.

  /**
   * Some comments ...
   */
  public int m7() {return 1;}  // violation

  /**
   * This
   * implementation ...
   */
  public int m8() {return 2;}  // OK. Have required javadoc.

  @Override                    // violation
  public String toString() {
    return "";
  }
}
        

Example of Usage

• Sun Style
• Checkstyle Style

Violation Messages

• design.forExtension

All messages can be customized if the default message doesn't suit you. Please see the documentation to learn how to.

Package

com.puppycrawl.tools.checkstyle.checks.design

Parent Module

TreeWalker