Java 使用空实现使抽象方法非抽象是否安全

假设我们有这样一个类：

public abstract class AbstractClass{

  protected abstract void validate() throws ValidationException;

  public void doAction() throws ValidationException{
    validate();
    //some more actions
  }
}

这个类有很多实现。我发现在90%的实现中，方法validate（）没有主体，也就是说，在90%的继承器中它是空的。我想将其重构为：

protected void validate() throws ValidationException{
   //empty body
}

---

这种重构是向后兼容的吗？

是的。在旧版本中，您必须实现它，现在每个实现都将覆盖它

没有任何东西（好吧，你可能有一些非常时髦的代码，但这不太可能）会崩溃，因为抽象方法的唯一特殊处理就是强制实现它。

用技术上的“它会工作吗？”术语来说，没问题。唯一一个立即浮现在脑海中的真正问题是长期维护问题：如果在某个时候它添加了代码，许多实现可能不会调用它，因为它过去是抽象的（例如，它们没有

super.validate（）

），因此它们将错过运行该（假设的）代码

---

另一个模糊的担忧是，这意味着子类作者不必停下来思考“我需要在

验证
中做些什么吗？”而在您当前的结构中，至少会提示他们考虑这个问题。
是的，它是向后兼容的。“这个类有很多实现。我发现在90%的实现中，方法validate（）没有主体，也就是说，在90%的继承器中它是空的。”-为什么？这是一种设计味道。--“这种重构是向后兼容的吗？“-好处是什么？这种方法不再使用了吗？如果是这样的话，把它从界面上移除。是时候去寻找新的设计了。我认为它或多或少是向后兼容的。可能有人使用某种类型的反射，期望
validate
是抽象的。这将是一个重要的版本。实际的问题是：提供一个空的“默认”实现有什么好处？如果不使用该方法，则应将其从接口中删除。在90%的情况下，有很多次方法未实现，但这并不意味着它未被使用。