• Post Reply Bookmark Topic Watch Topic
  • New Topic

Ways to provide default implementations for interfaces  RSS feed

 
Arco Brouwer
Ranch Hand
Posts: 44
2
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While diving into some Object Oriented concepts, I encountered the following.
When using interfaces to segregate certain behaviour, it is possible to provide a default implementation for certain methods if that is legitimate. One example that I have seen was as follows:
But if I'm correct, in Java 8 you are also allowed to use the default keyword to provide a default implementation for an interface method like this:
When a class implements this last example, it will automatically provided with the default implementation. As far as I know you are allowed to override this default method.
What I would like to know: Is there a difference in functionality between the two interface types, and is there a preferred way to provide a default implementation for an interface method?
 
Stephan van Hulst
Saloon Keeper
Posts: 7963
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem with a class that provides default implementations is that you can't inherit both the default implementation, and extend a different class. The problem with default methods of interfaces is that they can't access fields. As always, it depends on the situation.

Prefer default interface methods when you can implement them using properties that the interface already exposes. Don't add extra properties to the interface just to be able to implement the default method. Prefer abstract classes when you need private properties.

I'm not a fan of using a nested class for the abstract implementation. Instead, put it in a separate file and name it AbstractAdorable.
 
Stephan van Hulst
Saloon Keeper
Posts: 7963
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An example of an interface with default methods:

Because parent(), leftChild() and rightChild() are very reasonable properties for a binary tree node to expose, we can give default implementations for the isRoot(), isLeaf(), depth() and height() properties.

Now, it would be very useful if we also had a default implementation for the key() and value() properties, based on some private fields. We can provide an abstract class for this:

Concrete classes now only have to implement parent(), leftChild() and rightChild(), and they can also override depth() and height() if they can provide more efficient implementations (for instance, in case of a BinaryMinHeap).
 
Matt Wong
Greenhorn
Posts: 23
3
MS IE Notepad Suse
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe my two cents aren't a good "solution", but it could be a lead:

As I love interfaces, factories, mvc and likwise patterns - and to over-complicate even easy example codes - my personal prefernce is as follows:

Interface - as just an empty skeleton, maybe some final constants
AbstractImplementation - to provide default behaviour when possible/needed
Implementation - the actual impl itself
Factory - to create instance of implementations in an abstract way to hide object creation

Why? Because I love to work with modular parts. For the "user-level" code it doesn't matter how specific object is created, all it matters is its type defined by the interface.
So an easy example of Hello World would have at least an interface, an abstractImpl, an impl, a factory - and some magic hidden inside the factory to locate and load the impl from anywhere outside the main code/application.
Sure, for a HelloWorld this is overkill, but om other more complex projects it can be usefull - and it's easy to the test the different parts by themselfs.
 
Stephan van Hulst
Saloon Keeper
Posts: 7963
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Regardless of how "enterprisey" you make the code, it has nothing to do with whether default method implementations should be in the interface or an abstract class. It's an implementation detail.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!