Win a copy of High Performance Python for Data Analytics this week in the Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

What is the difference between abstract classes and Java 8 Interfaces?

 
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me try to put it in simple words. We should use interfaces when we want to define a contract to be followed by the classes implementing it, which may be unrelated. Abstract classes are classes which have atleast one abstract method which are required to be implemented by classes extending it. We should use abstract classes if we are expecting the classes implementing it to share many common methods or fields.
 
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well done checking I wasn't sure on that point. I knew there were such things as private methods but had forgotten all other details.
 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:. . . . Abstract classes are classes which have atleast one abstract method . . .

No, you can have abstract classes without any abstract methods.

We should use abstract classes if we are expecting the classes implementing it to share many common methods or fields.

Correct.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Well done checking I wasn't sure on that point. I knew there were such things as private methods but had forgotten all other details.



I had checked for private default methods but additionally what I can see is now there are static methods too in Interfaces.
 
Ranch Foreman
Posts: 175
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys!

I always look to see what has already been posted before posting anything, and that led me to this appropriate thread rather than starting a new one.

I also try not to post something every time I seem some Rando posting something dumb somewhere about how you should use Java that I disagree with, just to get an opinion on it, tho I sometimes do that if it seems like it might actually be a good idea to start doing something and I want to be sure.

However, if I see a very popular information source suggesting something I think is wrong, I very likely do ask about it, because many people are going to be reading it and getting misled.

In this case, I saw a very popular information source claiming that default methods, aka defender or virtual extension methods, can and should be thought of as dummy methods that will very likely need to be overridden in implementing classes to be of real use.

I replied in a public way saying this:
]

My understanding is that default methods are sometimes just dummy implementations in order to hold a place for something useful in a class that implements it,
but also, that sometimes they are perfectly useful just as is.
The code in a default implementation can't access any writable data members directly,
because interfaces even now contain only public static final data members.
But they can call other member methods of the interface that are implemented by the class,
and have logical meaning even in the default.
So thinking of them as "just dummies" is too limiting, because sometimes they are perfectly good combinations
of other methods you will be implementing, and there is rarely going to be a good reason to @Override them to make good use of them.
There are numerous examples of both kinds
(dummies that are useless as coded, and perfectly good ones to leave as is and make use of)
in default methods added by Sun/Oracle in interfaces in Java 8 and later.
It is too limiting to just think of them as dummies that need to be overridden to be useful.


Is what I said common consensus?  I feel like there are a fair number of default methods that have been added to standard interfaces that are too useful to be ignored, and are just great as they are, and there is little to no reason to @Override them, just use them and enjoy them and profit from them.

I read this whole thread and I feel like I would land differently on the balance between using Interfaces and Abstract Classes in a language that had both Interfaces and Multiple Inheritance.
The fact that Java does not have Multiple Inheritance makes me relatively reluctant to bite the bullet to go for an Abstract Class because we can casually implement as many interfaces as we need, but when it comes to a superclass, "There Can Be Only One".
 
Jesse Silverman
Ranch Foreman
Posts: 175
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have now read way, way, way more about this subject than I intended by plumbing the depths of the past four years of (VERY DEEP) discussions about this topic, and in particular default methods in interfaces.

My mind is a bit blown, there is so much to consider for the very thoughtful, so much discussion here of the principles by resident principals.

For reference, including my future reference, this thread included a substantial Brian Goetz quote on the topic:
https://coderanch.com/t/664980/java/interface-abstract-class

I think I had a point but there as usual there is way more to it than I was thinking.
I was mostly focused on nifty "convenience" methods he describes, tho some may be one of the other types as well.

I definitely feel that describing them as "dummies" just to get things to compile sells existing useful ones terribly short, and will definitely need to come back to the topic more than once when considering proper API and interface design in the future.

The discussions on the evolution of the Comparator interface alone will haunt my dreams for weeks....
 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there a consensus?

Default methods are intended to provide default implementations, so they are usually not “dummies”. Only blame Oracle for default methods; they weren't even thought of until Oracle took Sun over.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote: Only blame Oracle for default methods; they weren't even thought of until Oracle took Sun over.



Is there anything wrong with Default methods that Oracle is to be blamed for it?
 
Jesse Silverman
Ranch Foreman
Posts: 175
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The same guy promotes that since we can now have static methods in interfaces, it is a great and nifty idea to put a bunch of related utility methods into an Interface, instead of a class.

Historically, if I thought I had a bunch of related only static utility methods, I would place them in a final class with no public constructor, which is the closest I could come to a "static class" in Java, which I know is not a real term for a top-level class.

Now, in Java 8, I see that for sure we can do this, we can provide them all instead in an Interface.

It feels like Interface Abuse to me tho, Interfaces are meant to be Implemented, even Tag or Marker interfaces.
Definition of Interfaces that are never intended to be implemented seems weird or perverse, tho legal.

He claims there is some big performance benefit, and talks about needlessly instantiating objects of a Class.
But if the only methods we care about are static, there is no need to do that anyway -- I don't see any performance benefit.

If we later decide there are one or more instance methods we need, we can give the class a constructor.

If we provided the functionality via. an interface, we might throw in default methods, but if we needed any writable instance data to do it, we'd be hosed and looking at ourselves in the mirror and hating ourselves, I think.

My thought is that this is jumping on the "Hey, I could do this new thing, so it must be good" bandwagon.

Unless you are somehow certain that all of the methods that ever belong together are static, including some you didn't think of yet -- don't put them into an interface just because we can, you are painting yourself into a corner that a final class with no public constructor doesn't have.

I am not sure about this, but I had seen this popular dude mention this three times, so a lot of people, especially relative noobs, are getting exposed to this idea.

I read a LOT here about default and static methods, but did not see this point, about whether it is a great or a poor idea to group static utility methods into an interface instead of a class, addressed at a relatively beginner level.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think, although the gap between interfaces and abstract classes have decreased after the introduction of default methods and static methods in the interface, the primary difference remains that Interfaces are contract to be followed by the classes that implement it and Abstract classes are like partially implemented and partially yet to be implemented by subclasses.
 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Most abstract classes are partially implemented, but some are fully implemented. I have never tried writing an abstract class with final methods.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:but some are fully implemented.



But if it is fully implemented then how would it be abstract? What would be an example of fully implemented abstract class?
 
Jesse Silverman
Ranch Foreman
Posts: 175
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I recall correctly, the "Adapter Class" was described to me as a way to get away with implementing only part of an over-full interface.

My two overwhelming feelings were "Who made such a bloated interface that you feel you need to only implement part of it?" and "How are you sure that having these dummy stubs for parts you decide not to implement guarantees safe and effective operation?" but I memorized that it contains dummy/stub methods for each member of the interface, and that they recommended that it be declared abstract.

So, I haven't used Adapter Classes, and had the reservations mentioned above make me not in a rush to do so, but recall that they were described as having zero remaining abstract methods, yet it was recommended to still declare them abstract.
 
Saloon Keeper
Posts: 12628
273
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:Is what I said common consensus? I feel like there are a fair number of default methods that have been added to standard interfaces that are too useful to be ignored, and are just great as they are, and there is little to no reason to @Override them, just use them and enjoy them and profit from them.


I don't think there's consensus, but I agree with your point of view. I have written large interfaces that provided almost a complete implementation of themselves using default methods, where the simplest complete implementation only had to provide backing fields for properties exposed in the interface.

Granted, this is not a common case, but it does illustrate that "default" does not mean "dummy" or "placeholder", but rather means a sensible implementation that will work for ALL subtypes, and classes should only override it if they can make performance improvements or must account for specific edge cases that the interface doesn't know about.

The fact that Java does not have Multiple Inheritance makes me relatively reluctant to bite the bullet to go for an Abstract Class because we can casually implement as many interfaces as we need, but when it comes to a superclass, "There Can Be Only One".


Abstract classes are very useful as base implementations for categories of similar classes or indeed as adapters. For instance, a Tree interface can be implemented by an abstract ArrayBasedTree class that serves as a base class for for instance various heap implementations that conventionally store their nodes in an array. The tree interface can contain default methods that will work for ALL kinds of trees, such as a height() property. The default implementation would determine the height through recursion, but binary heaps can override it it with a more performant implementation that calculates the height based on the length of the array.

However, you should never provide an abstract class without first providing an interface it implements that other classes can also implement without relying on the abstract class.

Jesse Silverman wrote:Historically, if I thought I had a bunch of related only static utility methods, I would place them in a final class with no public constructor, which is the closest I could come to a "static class" in Java


Yes. Do NOT use interfaces in lieu of static utility classes. Interfaces must only be used as contracts for other classes to implement. Static methods in interfaces should only be used to break up default methods into smaller pieces and therefore should be private.

He claims there is some big performance benefit, and talks about needlessly instantiating objects of a Class.


Sounds like he doesn't know what he's talking about, or you misread the article.
 
Stephan van Hulst
Saloon Keeper
Posts: 12628
273
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:I think, although the gap between interfaces and abstract classes have decreased after the introduction of default methods and static methods in the interface, the primary difference remains that Interfaces are contract to be followed by the classes that implement it and Abstract classes are like partially implemented and partially yet to be implemented by subclasses.


Yes, this is the primary conceptual difference.

The primary technical differences are that abstract classes can contain fields, but a subclass can implement only one abstract base class, but multiple interfaces.

Campbell Ritchie wrote:I have never tried writing an abstract class with final methods.


I do this all the time. If you can't make a class final, you must make as many of its methods final as possible.
 
Stephan van Hulst
Saloon Keeper
Posts: 12628
273
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:My two overwhelming feelings were "Who made such a bloated interface that you feel you need to only implement part of it?" and "How are you sure that having these dummy stubs for parts you decide not to implement guarantees safe and effective operation?"


Have you ever used the visitor pattern before? Visitors are operations that rely on double dispatch in order to be applied to a wide range of subtypes:




So, I haven't used Adapter Classes, and had the reservations mentioned above make me not in a rush to do so, but recall that they were described as having zero remaining abstract methods, yet it was recommended to still declare them abstract.


If you have many different kinds of operations you want to apply to only a subset of all animals, then having to add empty implementations every time becomes very tedious. It's better to write an adapter:


As you can see in this example, AnimalVisitorAdapter has no remaining abstract methods, but the class itself is still abstract because it makes no sense to create an instance of it directly.
 
Jesse Silverman
Ranch Foreman
Posts: 175
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stephan:

I haven't fully digested your Visitor response yet, but +1 for keeping it in the theme for anyone working thru Jeanne and Scott's book, which uses Animals and Zoos thru-out.

I am open to the idea that tho the I in SOLID says not to over-stuff your interfaces with things that only some people will want to implement, there is indeed a need for Adapter classes, and here you provide a good example of it.

I had already memorized several things about them, so good to see that they are of more general use than dealing with Interfaces created by people who took the I out of SOLID.

I am not sure whether I had used the Visitor pattern or not.  There are many Design Patterns I eventually realize that I have used many times, but as I didn't use the name for them at the time, I didn't "know" I was using them.

I appreciate the movement towards having language-agnostic common terminology for these things so that they become easier to talk about, for exactly that reason: I often have used such a thing before, but it is much easier to talk about things that have a name.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic