Java 8 interface default methods vs. non-abstract methods in abstract classes
- are there any differences between the two (besides the differences of iface - class, visibility etc.)
Isn't a default method a step back in Java, meaning it's against the essence that Java has advertised for years?!
non-abstract methods in abstract classes will be called when it's concrete subclass calls super() if it is overridden. So there are multiple possibilities. If method is not overridden then the super class method will be executed. if we use super() in the concrete subclass method then the overridden method with the super class method will be executed.
Where as Java 8 interface default methods are completely different. It provided a choice to the developers to implement the method in the implementing class or not. If the function is not implemented then and only then the default method will be executed.
Possible Use Case :
The most important use case for this new feature in the JDK libraries is the possibility to extend existing interfaces without breaking existing implementers: adding a new abstract method to an interface would require all implementing classes to implement that new method.(Source)
The important thing to keep in mind is that default methods don't have access to state, only to behaviour. It is actually a great place to define reasonable, default, behaviour.
Imagine you have an interface:
public interface Plant {
enum Pace { FAST, SLOW; }
void grow(Pace pace);
void growFast();
void growSlow();
}
It seems reasonable to provide a default behaviour:
default void growFast() { grow(Pace.FAST); }
default void growSlow() { grow(Pace.SLOW); }
This is a simplistic example but shows how default methods can be helpful. In this case, the way growSlow or growFast behaves is part of the interface contract so it makes sense to define their behaviour at the interface level.
However the interface makes no assumption about how the action "grow a plant" is implemented. That could be defined in an abstract class.
Firstly Default methods allow you to add new methods to interface without breaking existing implementations.
Also take an example of Collections class which is a utility class for Collection interface right.
So using default methods we can now move all the utility methods as default implementation in the Collection itself, which will make more sense than making a separate class for such utilities.
Also you will be able to inherit methods from multiple interfaces, which could not have been done using plain abstract classes.
the big difference is that the constructor can possibly be run in an anonymous class, possibly with checked exceptions. this prevents anonymous classes being functional interfaces, and in turn makes them unavailable to use as the basis for a lambda expression.
The main differences are:
Java 8 default methods of interfaces are public, while non-abstract (concrete) methods of abstract classes can be defined as public, protected or private.
Lambda expressions got introduced in Java 8, to use lambda features we need default methods(to preserve backward compatibility), non-abstract methods of abstract classes can not serve the purpose.
Related
I am reading the Java documentation about interfaces and reached the chapter about default methods. As far as I understand, when you define an interface and later add methods to it, all classes that implement this interface will break and are in need of implementing the new method.
So the documentation briefly mentions static methods as an option to mitigate this problem, but also states, that they would be viewed as "utility methods" and not essential:
If they add them as static methods, then programmers would regard them as utility methods, not as essential, core methods.
Why is this the case / why would they be viewed as "not essential"?
static methods do not work on the instance of a class, but are part of the class itself. They are most often used for utility type of tasks and therefor a little bit contradict object-orientation so should be used sparsely.
But, default methods != static methods. The docs just mention the static methods there to show how before default methods something could have been added to an interface without breaking all implementations.
Default methods are another way to add functionality to an interface without breaking existing impementations by specifying a default implementation for that method (even if it is just a throw new NotImplementedException()). And these methods can be implemented by the concrete classes that implemented this interface to provide the actual functionality they are meant for and thus overriding the default implementation of the method.
With static methods this is not possible, as they belong to the class object, not the instance and thus cannot be overridden by subclasses or implementations.
Because you call static methods generally on class not on the Interface, eg:
Integer.parseInt(); - is called on concrete class Integer
Because static methods are self-contained, they don't depend on other methods in an interface. And more over most of the static methods in java code are actually utility methods.
This question already has answers here:
When to use: Java 8+ interface default method, vs. abstract method
(16 answers)
Closed 7 years ago.
Why We need Defender methods in interfaces in java 8 as we already have abstract classes.I found various answers on internet like:
To add external functionality
But Abstract class is for partial Abstraction where as our interface is actually a pure abstract class so why their is a default method inside an interface?
The problem with sharing functionality by placing it in an abstract base class is that a class can derive from exactly one base class. This is a limitation in cases when you would like to inherit functionality from more than one base.
Sharing functionality through an abstract base class may also become a problem when you need to implement an interface from a class that already has a base class. In this case you cannot derive your new class at all, because you must pick one of the two bases, when presumably you want both.
Default methods solve this problem with elegance: placing your common implementation into the default method allows you to share the code without limitations.
You can think of the main difference between default methods and inheriting an abstract class as the difference between sharing functionality horizontally across siblings that implement the same interface, or vertically among children that inherit from the same base class.
Here is an examoke: consider an interface that looks like ResultSet of JDBC, which has two ways of accessing the same column - by name and by index. The interface could be coded up like this:
interface ResultSet2 {
int findColumn(String columnLabel);
String getString(int index);
long getLong(int index);
default long getLong(String columnLabel) {
return getLong(findColumn(columnLabel));
}
default String getString(String columnLabel) {
return getString(findColumn(columnLabel));
}
}
Anyone implementing ResultSet2 would have to implement three methods, and get the remaining two for free. They would have an option to provide an alternative implementation, but that would be optional.
The main reason behind defender methods is to be able to extend long-existing interfaces with new functionality, without breaking the existing code. Particulary with Java 8 lamba expressions they introduced a lot of new methods on collection interfaces, like Iterable.forEach. With providing default methods, existing classes implementing the Iterable interface dont have to be altered to use in Java 8 environment.
The original intent was to compete with C#'s extension methods. Given core methods of an interface, e.g. get(), set() in List, extention methods (e.g. sort()) can be defined and implemented.
Java guys argued that it would be better to declare such methods on the interface itself, rather than in external places; so that the methods could be overridden by subtypes, providing optimal implementations per subtype. (They also argued that such methods should be controlled by the interface authors; this is rather a soft point)
While default methods can be added to existing interfaces, it is very risky of breaking existing 3rd party subtypes, particularly for very old types like List with lots of subtypes in the wild. Therefore very few default methods were added to existing core Java APIs. See this question.
For new interfaces, default method is a very valuable tool for API designers. You can add a lot of convenience methods to an interface, for example, Function.compose(). Subtypes only need to implement abstract/core methods, not default methods (but they can if they want to).
I disagree with the idea that default methods can "evolve" interfaces. They do not change the core semantics of an interface, they are just convenience methods (in the form of instance method).
And default methods should be carefully designed up-front when the interface is designed; as said, it is very risky to add default methods afterwards.
C#'s extension method allows 3rd party to add convenience methods; this is very nice, and there is no reason why Java couldn't introduce something similar in future.
I know this might be crazy but today one of my friend puzzled by asking when we implement an interface in java is it considered as method overriding. I told him it is not overriding as we are providing working(definition) of method first time when we implement any interface. To support multiple inheritance java provide interface but he was not convinced and was arguing. Please bring some light on to the topic.
The term "overriding" applies when there is an existing implementation of the method . The correct term is "implementing" for interfaces and other abstract declarations.
The #Override tag is used for both cases - it is used when:
The method does override or implement a method declared in a supertype. --javadocs
And from Wikipedia:
Method overriding, in object oriented programming, is a language feature that allows a subclass or child class to provide a specific implementation of a method that is already provided by one of its superclasses or parent classes.
Note that interfaces can have default methods - redefining these methods overrides them:
When you extend an interface that contains a default method, you can ... redefine the default method, which overrides it.
Besides linking to "canonical" sources, I'm not sure what advice to offer on winning a semantic argument with your friend. Perhaps you could ask him what the distinction is between "implementing" and "overriding", and what word he would use instead of "overriding" for the concept of redefining an existing method.
At first glance, interfaces just define API. Since there is no super method to override, the implementations is the first method.
But since Java 5, it's customary to add #Override annotations even for methods which come from interfaces. The main reason here is to catch problems which happen when people change an interface: Now you have a method which is "dangling" - there is no API which says that the method has to be there. The annotation causes an error if you remove a method from the interface, catching this so you can properly clean up all the code.
But that still doesn't mean the implementing method overrides anything.
Except that an interface is very much an abstract class with abstract methods in the byte code. And abstract methods do override.
My feeling is that you can argue both ways but the argument is moot unless you have a use case there the answer to the question actually has a real impact on the code. And here, it doesn't really matter since the compiler hides all the ugly details.
This question already has answers here:
Purpose of Default or Defender methods in Java 8
(5 answers)
Closed 8 years ago.
I'm taking a look to Java 8 news compared to 7 and in addition to very interesting things like lambdas or the new time framework, i found that a new feature(?) was introduced: default methods.
I found the following example in this article:
public interface Math {
int add(int a, int b);
default int multiply(int a, int b) {
return a * b;
}
}
It seems very strange to me.
Above code looks like an abstract class with an implemented method. So, why to introduce default methods in an interface? What is the actual advantage of this approach?
In the same article I read this explaination:
Why would one want to add methods into Interfaces? We’ll it is because interfaces are too tightly coupled with their implementation classes. i.e. it is not possible to add a method in interface without breaking the implementor class. Once you add a method in interface, all its implemented classes must declare method body of this new method.
Well this doesn't convince me at all. IMHO I believe that when a class implements an interface obviosly must declare methods body for each method in it. This is surely a constraint, but it's also a confirm of its "nature" (if you understand what I mean...)
If you have common logic to every inheriting class you'll put it into an implementing abstract class.
So, what's the real advantage of a default method? (It looks more like a workaround than a new feature...)
UPDATE I understand that this approach is for backwards compatibility, but it still doesn't convince me so much. An interface represent a behaviour that a class MUST have. So a class implementing a certain interface has surely this behaviour. But if someone can arbitrarily change the interface, this constraint is broken. The behaviour can change anytime... Am I wrong?
This is for backwards compatibility.
If you have an interface that other people have implemented then if you add a new method to the interface all existing implementations are broken.
By adding a new method with a default implementation you remaining source-compatible with existing implementations.
For a slightly simple/contrived example that should hopefully demonstrate this let us say you created a library:
void drawSomething(Thing thing) {
}
interface Thing {
Color getColor();
Image getBackgroundImage();
}
Now you come to do a new version of your library and you want to add the concept of border colors, that's easy to add to the interface:
interface Thing {
Color getColor();
Color getBorderColor();
Image getBackgroundImage();
}
But the problem is that every single person using your library has to go back through every single Skin implementation they ever did and add this new method.
If instead you provided a default implementation to getBorderColor that just called getColor then everything "just works".
There have been a lot of methods acting on an abstract interface in the past. Before Java 8 they had to be put into an additional class pairing the interface, e.g. Collections with Collection.
This old approach was neither more convincing than default methods nor more practical. Instead of list.sort() you had to say Collections.sort(list). This also implies that you had to make a fundamental decision when creating an interface, either you require every List implementation to implement a sort method or you provide a sort method in a utility class that cannot be overridden.
With default methods you can have both, a standard implementation which the List implementations do not need to implement on its own but still can be overridden if a concrete implementation has a more efficient way to do it knowing its internals, e.g. ArrayList.sort passes its internal array directly to Arrays.sort skipping some intermediate operations.
Suppose at some point you want to add new functionality in declared interface, up to Java 7, If you will add a new method in declared an interface, you also have to define the implementation of the method in classes that are implementing that interface.
In java 8, You can add a default method containing the implementation and all the child class will inherit that method.
Edit : (After question update)
An interface represent a behaviour that a class MUST have
It still represent a behaviour that class must have, your confusion is how you are defining behaviour. All implementing class will inherit default method and are also free to write their own implementation. consider following two cases,
If implementing class does not provide own implementation and simply inherit default method. If you change behaviour of default method in interface, implementing classes will be having updated behaviour as they inherit default method so it holds An interface represent a behaviour that a class MUST have.
If implementing class provide own version of default method, and if you will change behaviour (only arguments) of default method. In this case implementing class will be having two overloaded methods, one which was earlier defined and second one is inherited default method. and if you change complete behaviour (arguments with return type also), It will create ambiguity in implementing class as you can not overload method by changing return type and Implementation will be broken. again it holds An interface represent a behaviour that a class MUST have.
Example :
Bulk data operation in collection is added in Java 8 (Reference : http://openjdk.java.net/jeps/107), to implement that forEach() method is added in Iterable interface. Adding abstract method in Iterable interface would break all the existing code because each class has to implement that method.
Solving the issue, following default forEach() method is added in Iterable interface,
interface Iterable
{
default void forEach(Consumer<? super T> action)
{
for (T t : this) action.accept(t);
}
}
Reference : Java 8 : Default method in Interface
This question already has answers here:
When to use an interface instead of an abstract class and vice versa?
(26 answers)
Closed 8 years ago.
Can anyone tell me what exactly the difference between an completely abstract class and an interface?
An Abstract class can also have all its methods as abstract. An interface has all its methods as abstract. What is the main difference between the two in this scenario?
If there is difference between a pure abstract Class and interface? What is the use of interface? Where interface is being used we can make use of pure abstract class?
To complete the former answers :
An interface is a "contract". If a class implements an interface it have to propose all the services listed in the interface.
An abstract class is a skeleton. It defines a certain way its extended classes will work while letting them some free space (the abstract methods) to be unique.
A pure abstract class doing the same thing as a interface but have the problem of unique extending so, for me, it have no interest
Every interface is implicitly abstract: Every method declaration in the body of interface is implicitly abstract and public.
An abstract class has methods that can contain implementation. Abstract methods can be either public, protected or default access (package visible). Unlike interfaces abstract classes can contain fields that are not static and final.
Also see:
Interfaces vs Abstract classes and the
Java tutorial
In Java and C#, one can use multiple interfaces to derive from and only a single class to inherit from,
One reason to choose pure abstract over interface is to force sub classes to implement particular methods that are implemented by a super class.
For example (in Java),
Say you want all extending classes to implement toString(), equals(), and hashCode().
You could create an interface called ForceSomeMethods for that contract, but those methods are implicitly implemented by Object.
Making ForceSomeMethods a pure abstract class with toString(), etc as abstract methods, all subclasses will be forced to implement those methods.
It's not a very theorotical explaination but, programatically it's all correct
Interface Abstract Class
Extend Class No Yes
Extend Abstract Class No Yes
Implement Interface Yes(Extend Interface) Yes
Variables Public Static Final Public/Protected/Private/static/final/transient/volatile
Contain Non-Public Method No Public/Protected/*Private
Contain Abstract Method Yes Yes
Contain No-Body, Non-Abstract Method Yes No
Contain Defined Method No Yes
Contain Main Method No Yes
*Abstract classes can have private methods, but not abstract private methods.
An abstract class can provide an implementation, i.e. (public, protected, private) method bodies. An interface can just declare public method signatures. These methods have to be realized (in the form of method bodies) by classes implementing the interface.
There are three differences:
Interfaces can only declare public methods (i.e. no protected or package-private visible methods) and can not declare any fields
Subclasses can only extend at most one abstract class, but can implement any number of interfaces
The abstract class can also have implementations for some or all of the methods
I'm just going to address one point (mainly because the other questions have been addressed already):
"Where interface is being used we can
make use of pure abstract class?"
In theory, you could. However, you will lose flexibility and loose coupling to some extent. It's far more preferable to code to interfaces and pass those around, especially in Inversion of Control (IoC) scenarios and from an integration point of view, as this allows far greater extensibility.
Since the question is about pure abstract classes then I'd say the answer is going to be related to inheritance and scope. It's something I've wondered myself many times and this is what I've come up with.
Obviously the features related to multiple inheritance have been answered previously so I won't go in to any of that. Scope is a big one though.
In an interface you can't define a member's access modifiers since they are implicitly public,...you are defining the public interface for it's eventual implementation. There's an important difference there since you can define a protected abstract member in a pure abstract class.
Inheriting from such a class definition would force the inheritor to implement the abstract member but scope it privately to consumers of the class (though it would have to be defined as protected so unless the class was marked as sealed further inheritors would have access).
In essence you can define a private interface using pure abstract classes. Whether that's a good idea is a different question altogether but one good use I've seen it used for is to enforce design patterns and standardize class designs.
HTH
You can use Interface for multiple inheritance, but you can't use abstract class for multiple inheritance.
All the methods in Interface is public by default, by in abstract class, only the methods which you've set as an abstract need to be declared public.
A class can implement multiple interfaces, but only extend from one class (abstract or otherwise). If you need to specify an interface, then you should use an interface, so that classes may implement multiple of your interfaces.