Is it good practice to override non abstract methods?

Question

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.

Namara

"Is it a good practice in Java to override a non-abstract method?" Yes. – Soutor

Are you sure Inheritance is the right way to go here? I'd read this before deciding. – Eurythmic

Answer 1

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.

Karilla

I did not quite understand the last statement, could you please give an example of this statement: "Like: the base class having a fixed (final) method doing things - and that method calls other abstract methods to do its job." – Namara

Answer 2

Is it a good practice in Java to override a non-abstract method?

Yes. (But, make sure, you are not violating Liskov Substitution Principle (referring SO existing post), which tells Child classes should not break the parent class type definitions. For example, walk () method overriden from Animal class should perform (have behavior of) walking, it shouldn't perform flying or something else.)

I would also recommend to go through SOLID Principle for understanding design principle.

and what would be the difference conceptually b/w overriding non-abstract vs abstract methods.

There are no difference AFAIK. But, just to be clear, abstract method doesn't contain any implementation and you MUST override where as non-abstract method can be overriden.

Etymon

Answer 3

Overriding a non-abstract method is perfectly fine, and commonly practiced, as long as you don't violate the Liskov Subsitution principle:

Liskov's principle imposes some standard requirements on signatures

• Contravariance of method arguments in the subtype.
• Covariance of return types in the subtype.
• No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype.

In addition to the signature requirements, the subtype must meet a number of behavioral conditions.

• Preconditions cannot be strengthened in a subtype.
• Postconditions cannot be weakened in a subtype.
• Invariants of the supertype must be preserved in a subtype.
• History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Because subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this.

As long as the method still abides the contract once overriden, there should be no confusion as to what the new implementation does. The method's new implementation should still abide the same contract as the implementation before it was overriden.

Aristocratic

Answer 4

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

For example : If you consider toString() and hashCode() in Object class both methods are non abstract methods but it is mostly recommend to override those methods in our subclasses.

Because if I want to execute my logic instead of super class logic need to override and use it, it is recommended to override in this type of situations.

Vercingetorix