Menu
This is general coding practice to use interface/base class reference when declaring an object like :
InterfaceIF ref = new SomeObject();
I understand that this provides loose coupling and we can change/write a new class with new implementation without affecting much code.
This is wonderfully explained here also.
But one thing which I am trying not able to understand, and is not answered on the question is :
834
The fourth difference between abstract class and interface in Java is that abstract class are slightly faster than interface because interface involves a search before calling any overridden method in Java.
The performance of an abstract class is fast. The performance of interface is slow because it requires time to search actual method in the corresponding class. It is used to implement the core identity of class. It is used to implement peripheral abilities of class.
In Java, an interface is a reference type similar to a class that can contain only constants, the method signatures, default methods, and static methods, and ts Nested types. In interfaces, method bodies exist only for default methods and static methods. Writing an interface is similar to writing to a standard class.
An interface is a reference type in Java. It is similar to class. It is a collection of abstract methods. A class implements an interface, thereby inheriting the abstract methods of the interface. Along with abstract methods, an interface may also contain constants, default methods, static methods, and nested types.
Using the class directly may be faster, never slower. If the JVM sees a concrete class, it sort of knows "who to call". Not necessarily exactly as there may be subclasses, unless the class is final. There may be even subclasses not yet seen by the JVM which gets loaded later.
For a final class the method call can be optimized to the native CALL instruction. That's the trivial case.
If the class isn't final but there's no subclass loaded yet, it's the same with a single additional check somewhere at the beginning. When the check fails, the JVM must throw this over-optimistically compiled method away and recompile (no big deal).
When there are subclasses, then everything depends from how many of them were actually encountered on the given call site. If only one, then a fast check suffices to verify that the given class is the expected one (by moving this test out of loops etc., this overhead becomes negligible).
The cases with more candidates are obviously slower (Google for bimorphic and megamorphic).
Obviously, there's nothing what could make a call via an interface faster.
If there are multiple implementations and more than one gets called from a call site, then there's an overhead of the virtual call dispatch. For more details see this answer and this benchmark.
149
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
