Considering that interfaces now can give an implementation to the methods it provides, I cannot properly rationalize the difference between interfaces and abstract classes. Does anyone know how to explain the difference properly?
I was also told that interfaces are somewhat more light-weight compared to abstract classes, performance wise. Can someone confirm this?
Interfaces still can't have any state. Interfaces still can't have any final method, which means that any implementation can override all its default methods. And interfaces still can't have any constructor.
You can still implement multiple interfaces, even if they have default methods with the same signature. You can't extend multiple classes (abstract or not).
Default methods are restricted to input parameters and method calls. They are stateless in nature. An abstract class may have state. Hence, from the perspective of design, I would suggest to use abstract classes whenever you need code reuse. Reducing code reuse to package scope is a good design principle in my opinion.
Interfaces are perfect to model and communicate the concepts of a package, a library, a domain or an application. They do not rely on implementation details and allow to replace the implementations at will. They support testing and modularization.
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