覆盖非抽象方法是一种好习惯吗?

时间:2018-01-06 06:09:55

标签: java oop inheritance override abstract-methods

我有一种情况需要修改超类方法以获得子类特定逻辑,但方法逻辑对于所有其他子类是相同的。

我有两个选择:

1)使方法成为抽象,除了我所关心的子类之外,重复相同的代码。

2)重写有关子类中的非抽象方法,我想要改变逻辑。

用Java覆盖非抽象方法是一种很好的做法吗?什么是概念上b / w覆盖非抽象方法和抽象方法的区别。

4 个答案:

答案 0 :(得分:6)

在某种程度上,这是一种风格问题。

这是一种常见的练习 - 但也有人告诉您任何方法都不应该有多个实现。这些人声称继承层次结构中的多个实现会导致难以调试的代码 - 因为您必须非常小心地确定实际调用此类方法的哪个版本。

当这些方法被其他方法大量使用时,你可能很容易忽略大局 - 突然之间,由于某些子类中的重写,所以很难预测某些代码正在做什么 -

要了解的:a" single"对于X类中的某些方法foo()的@Override是很好的,也是常见的好习惯。但是在X的子类中重写相同的foo() - 这很快就会导致各种问题。

换句话说:应该仔细地重新实现非抽象方法。如果它使您的代码更难理解,那么寻找其他解决方案。比如:具有固定(最终)方法的基类 - 该方法调用其他抽象方法来完成其工作。例如:

public abstract class Base {
  public final int doSomething() {
    String tmp = foo();
    int result = bar(tmp);
    return result * result;
  }
  public abstract String foo();
  public abstract int bar(String str);

如上所述:您可以看到实施是"已修复"因为doSomething()是最终的 - 但是必需的"成分"可以(必须)在每个子类中重写。

答案 1 :(得分:6)

  

用Java覆盖非抽象方法是一种很好的做法吗?

是。 (但是,请确保,您没有违反Liskov Substitution Principle(引用SO现有帖子),这告诉Child类不应该破坏父类类型定义。例如,walk ()方法覆盖{{1} } class应该执行(有行为)行走,它不应该执行飞行或其他事情。)

我还建议您通过SOLID Principle了解设计原则。

  

在概念上b / w覆盖会有什么区别   非抽象与抽象方法。

AFAIK没有区别。但是,为了清楚起见,抽象方法并不包含任何实现,并且必须覆盖非抽象方法可以覆盖的位置。

答案 2 :(得分:1)

覆盖我想要改变逻辑的有关子类中的非抽象方法 - 是

例如: 如果在Object类中考虑toString()和hashCode(),则两个方法都是非抽象方法,但建议在子类中覆盖这些方法。

因为如果我想执行我的逻辑而不是超类逻辑需要覆盖并使用它,建议在这种情况下覆盖它。

答案 3 :(得分:1)

只要你没有违反Liskov Subsitution principle,覆盖非抽象方法就完全没问题了,并且通常都会实践:

  

Liskov的原则对签名强加了一些标准要求

     
      
  • 子类型中方法参数的反演。
  •   
  • 子类型中返回类型的协方差。
  •   
  • 子类的方法不应抛出新的异常,除非这些异常本身是超类型方法抛出的异常的子类型。
  •   
     

除了签名要求外,子类型还必须符合许多行为条件。

     
      
  • 无法在子类型中加强先决条件。
  •   
  • 后置条件不能在子类型中被削弱。
  •   
  • 超类型的不变量必须保留在子类型中。
  •   
  • 历史约束(“历史规则”)。对象被认为只能通过他们的方法(封装)进行修改。因为子类型可能引入超类型中不存在的方法,所以引入这些方法可能允许子类型中的状态更改在超类型中是不允许的。历史限制禁止这样做。
  •   

只要该方法在覆盖时仍然遵守合同,就不应该对新实现的作用产生混淆。该方法的新实现仍应遵循与覆盖之前的实现相同的合同。