Is it good practice to override non abstract methods?

Learner :

I have a situation where I need to modify the super class method to have a subclass specific logic, but the methods logic is same for all other subclasses.

I have two options:

1) make the method abstract and for each except my concerned subclass repeat the same code.

2) Override the non-abstract method in the concerned subclass where i want to have alter logic.

Is it a good practice in Java to override a non-abstract method? and what would be the difference conceptually b/w overriding non-abstract vs abstract methods.

GhostCat salutes Monica C. :

To a certain degree this is a matter of style.

It is a common practice - but there are also people that tell you that any method should not have more than one implementation. These people claim that multiple implementations within an inheritance hierarchy lead to code that is hard to debug - because you have to be extremely careful to determine which version of such a method is actually called.

And when such methods are used heavily by other methods you can easily loose the big picture - all of a sudden it becomes complicated to anticipate what some code is doing - because of heavy overriding in some subclasses.

The key thing to understand: a "single" @Override for some method foo() in class X is fine, and common, good practice. But overriding the same foo() again in subclassses of X - that can quickly lead to all kinds of problems.

In other words: re-implementing non-abstract methods should be done carefully. If it makes your code harder to understand then look for other solutions. Like: the base class having a fixed (final) method doing things - and that method calls other abstract methods to do its job. Example:

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);

As written: here you can see that the implementation is "fixed" because doSomething() is final - but the required "ingredients" can (must) be overridden in each subclass.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=442857&siteId=1