A concrete implementing class of an interface that declares a default method does not have to provide an implementation for the default method whereas a concrete subclass of an abstract class has to provide an implementation for all the abstract methods in its class hierarchy.
Also a class can implement multiple interfaces but it can extend only one class ( abstract or not).
I think default methods help libraries to evolve in later releases.
We see a lot of default methods added to the Collection interface in Java 8, for example the stream methods. Now because they are default methods, the existing implementations have no obligation to provide an implementation for such methods and the designers have the flexibility of providing an implementation in specific classes they want to evolve.
Prior to Java 8, I think the designers had to majorly rely on a thing like UnsupportedOperationException to do that sort of a thing.
Nandhini, there is a really nice thread about the default methods that talks about some of the practical things we must consider before we start coding interfaces with default methods at all in our code. I really liked that thread and I feel that you might also benefit from reading it, just like I did ( I am yet to process all of it -- it will take me some time ).
Joe Bishara wrote:An interface cannot contain an implemented method which affects instance state. An abstract class can.
Actually an interface can, but only through methods defined on the interface itself. Map.putIfAbsent is a good example. It is a default method of the Map interface that can most definitely affect state. It does so by calling existing methods get and put.
What you probably mean is that an interface cannot contain state of itself, in the form of fields.
The default method implementations in interface can be equivalent to the methods defined in the abstract class.
The methods declared in the interface is equivalent to the abstract methods in the abstract class
In a way, we are redefining the abstract class features in interface. With prior to Java 8, Interface has an advantage of multiple inheritance but abstract classes cannot.
But the advantage of the feature introduced in interface, to me is to have the backward compatibility. Meaning, the already existing contract between the interface and the classes would not be broken by defining the new methods within an interface.
Is there anything else other than this is happening with this new feature?
"This enables you to define methods that can access and modify the state of the object to which they belong."
seems to suggest that only methods defined in abstract classes can access and modify the state of an object, but methods defined in interfaces can also access and modify the state of an object.
Here's an excerpt from "Java 8 in Action" (emphasis mine) :
Urma, Fusco, & Mycroft wrote:Default methods are added to Java 8 largely to support library designers by enabling them to write more evolvable interfaces. ... They’re important because you’ll increasingly encounter them in interfaces, but because relatively few programmers will need to write default methods themselves and because they facilitate program evolution rather than helping write any particular program, we keep the explanation here short and example-based: ...
Chapter 9
... Default methods are a new feature added in Java 8 to help evolve APIs in a compatible way
The authors do give two other use cases for usage of default methods:
You can create your own interfaces that have default methods too. You may want to do this for two use cases that we explore in this section: optional methods and multiple inheritance of behavior.
I'll post a followup to give a summary of what those mean later. In the meantime, if you have the "Java 8 in Action" book, look it up in section 9.3
So it looks like the first additional use case mentioned, optional methods, is basically what you can accomplish pre-Java8 with an abstract base implementation class. The example given is the remove method of the Iterator interface in Java8 which provides an implementation that simply throws an UnsupportedOperationException. This will supposedly help reduce the amount of boilerplate code that implementers have to write. Ok, well write an abstract base implementation class that does the same thing, why don't you ¯\_(ツ)_/¯
I remain convinced that these and any other use cases apart from the main one, that of evolving well-established and widely-used interfaces, for default methods should be approached with extreme care and consideration. But then again, I might just be an old FUDdy-duddy Luddite when it comes to this... back to my MongoDB lessons!
Thanks @Junilu for your insightful post. From your post, I can deduce that the main difference between an interface and an abstract class is multiple inheritance. Methods (non-final, non-static, non-private) defined in an abstract class are limited by single-class inheritance i.e. the methods are inherited by related classes. Methods (non-static) defined in an interface are inherited by unrelated classes.
"This enables you to define methods that can access and modify the state of the object to which they belong."
seems to suggest that only methods defined in abstract classes can access and modify the state of an object, but methods defined in interfaces can also access and modify the state of an object.
The main difference of course being that an abstract class can access and modify the state through both methods and fields, whereas interfaces (which do not have any fields that are not public static final) can only use methods.
Post by:autobot
You've gotta fight it! Don't give in! Read this tiny ad:
a bit of art, as a gift, that will fit in a stocking