• 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
  • Tim Cooke
  • Paul Clapham
  • Devaka Cooray
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Liutauras Vilda
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Piet Souris
Bartenders:
  • salvin francis
  • Carey Brown
  • Frits Walraven

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

 
Ranch Hand
Posts: 1415
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The difference between abstract classes and interfaces was that interfaces did not have methods but with java 8 even interfaces can have methods so what is the difference left? thanks
 
Marshal
Posts: 68936
275
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try running this code:-
 
Monica Shiralkar
Ranch Hand
Posts: 1415
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On trying this code, it gave errors:



Illegal modifier for the interface field Foo.i; only public, static & final are permitted

Interfaces cannot have constructors.

A default method cannot override a method from
java.lang.Object
 
Campbell Ritchie
Marshal
Posts: 68936
275
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which version of Java® are you using?
What happened when you changed interface at the beginning to abstract class?
 
Monica Shiralkar
Ranch Hand
Posts: 1415
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am using Java 8. If I change it to abstract class other errors disappear but below error is there :

A default method cannot override method from java.lang.Object
 
Campbell Ritchie
Marshal
Posts: 68936
275
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are only allowed default methods in interfaces.
 
Monica Shiralkar
Ranch Hand
Posts: 1415
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But the code which you pasted has default method .I just created interface with that name Foo and pasted the same code.
 
Saloon Keeper
Posts: 11899
253
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell wrote that code to show you the difference.

  • Interfaces may not have instance fields.
  • Interfaces may not have constructors.
  • When declaring a default method implementation in an interface, you need to use the default keyword.

  • Abstract classes don't have these restrictions. On the other hand, you can not directly derive a class from more than one abstract class, while you CAN directly derive a type from more than one interface.

    In general, prefer interfaces. Abstract classes should only be used when you want to give a default implementation that depends on private properties.
     
    Campbell Ritchie
    Marshal
    Posts: 68936
    275
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:. . . I just created interface with that name Foo . . .

    And you couldn't get it to compile any more than I could.
     
    Monica Shiralkar
    Ranch Hand
    Posts: 1415
    8
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    In case of Abstract class , the classes implementing it come in the hierarchy and have something in common. In case of Java 8 Interfaces, the classes implementing it do not have much in common except for the default method. I will read on the reason why the 8 interfaces were introduced.
    thanks.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 11899
    253
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I don't see how you drew that conclusion.

    Why would classes that implement the same interface not have anything in common except the default method?
     
    Monica Shiralkar
    Ranch Hand
    Posts: 1415
    8
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:I don't see how you drew that conclusion.

    Why would classes that implement the same interface not have anything in common except the default method?



    Apart from that it will also have the constants of the interface common.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 11899
    253
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    What about declared method signatures, generic type parameters and inherited interfaces?

    Really, I would say that classes that inherit the same interfaces have more in common than you think.
     
    Monica Shiralkar
    Ranch Hand
    Posts: 1415
    8
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Two classes implement serializable interface . They may be totally different . But two classes extending an abstract class will not be so much different .
     
    Campbell Ritchie
    Marshal
    Posts: 68936
    275
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    That varies from interface to interface. Serializable is a tagging interface, so two classes can be very different, but if they both implement ResultSet, they will shares common methods.
     
    Monica Shiralkar
    Ranch Hand
    Posts: 1415
    8
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    have more in common than you think



    OK but lesser similarity than in case of classes implementing abstract classes.?
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 11899
    253
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Again, I don't see how you draw that conclusion.
     
    Sheriff
    Posts: 15527
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Pretty much the main difference is that an abstract class and its implementing subclasses are in the same class hierarchy. Interfaces and its implementations don't need to be in the same inheritance hierarchy.
     
    Rancher
    Posts: 3507
    37
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I think it's probably true, on average, that two different subclasses of a single abstract class probably have more in common than two different implementations of a single interface.  That's partly because originally, interfaces couldn't have default or static methods, so it was harder to share code between any implementations, and in fact abstract classes were the standard mechanism for doing so.  But it's not true as an absolute statement - two implementations of java.util.Map probably have a lot more in common than two subclasses of javax.swing.event.MouseAdapter, for example.  And I'm not sure it's a very useful statement either way.
     
    Junilu Lacar
    Sheriff
    Posts: 15527
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Mike Simmons wrote:And I'm not sure it's a very useful statement either way.


    This is probably the best way to summarize it all. I agree, it seems like a moot point.
     
    Monica Shiralkar
    Ranch Hand
    Posts: 1415
    8
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    thanks. I think if hierarchical structure is involved, it will be abstract classes and not interfaces. In case of abstract classes, the implementing classes must be related whereas in case of interface the implementing classes may or may not be related. For example in case of an animal type and sub types cat and dog doing bark, the subtypes are related. So it cannot be interfaces and has to be abstract classes.
     
    Junilu Lacar
    Sheriff
    Posts: 15527
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:For example in case of an animal type and sub types cat and dog doing bark, the subtypes are related. So it cannot be interfaces and has to be abstract classes.


    Not anymore. Again, with default methods, these relationships can just as easily use interfaces.

    What exactly is the practical point to all this? If it's just for understanding, it seems to me you're still not getting it.
     
    Monica Shiralkar
    Ranch Hand
    Posts: 1415
    8
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Point is when to use abstract classes and when to instead use Java 8 Interfaces?
     
    Campbell Ritchie
    Marshal
    Posts: 68936
    275
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:. . . in case of an animal type and sub types cat and dog . . . it cannot be interfaces . . .

    Not at all; it is quite possible to implement LifeForm or Animal or Carnivore interfaces.
     
    Junilu Lacar
    Sheriff
    Posts: 15527
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:Point is when to use abstract classes and when to instead use Java 8 Interfaces?


    My rule of thumb is to prefer interfaces over abstract classes. I can't remember the last time I've created an abstract class, honestly. If all you're interested in is the contract for behavior, which is most of the time anyway, then use interfaces. If you think there's something to gain by having a more concrete superclass-subclass relationship, then use abstract classes as your foundation. I think a class hierarchy imposes more restrictions on your design because you have to think about inheritance and the semantics of equals() and a bunch of other considerations that Joshua Bloch explains quite thoroughly in his book "Effective Java Programming".
     
    Mike Simmons
    Rancher
    Posts: 3507
    37
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I agree with Junilu.  Put another way: use interfaces first.  When you find things you need (or at least, that you have a good use for) that you can't do with interfaces, then try using one or more abstract classes in addition to interfaces.  Typically those abstract classes should probably implement interfaces defining most of their methods.  There are specific types of code that you can't share with interfaces, but can with abstract classes - e.g. with classes, you can have constructors and fields, and private and protected methods, that can be used by subclasses.  Private methods can't be invoked directly by subclasses of course, but they can benefit indirectly.   Those are all things you can't do with interfaces.

    Also remember - interfaces are primarily for defining an API, not for sharing implementations.  So, if you've got some code in a private method, that you want to share between classes, don't put it into an interface default method just so you can share it.  That makes it a public method - and initially it was a private method.  So you need to ask, is this really a method that should be part of the public API for your class?  Or is it something that should remain a hidden implementation detail.  If the latter, consider other ways of code sharing, like using a protected method in an abstract or base class, or making it a static method or a public method of some other class.  Default methods are good for some things, but don't overuse them in places where they don't make sense.
     
    Junilu Lacar
    Sheriff
    Posts: 15527
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Mike Simmons wrote:... you need to ask, is this really a method that should be part of the public API for your class?  Or is it something that should remain a hidden implementation detail.  If the latter, consider other ways of code sharing, like using a protected method in an abstract or base class, or making it a static method or a public method of some other class.  Default methods are good for some things, but don't overuse them in places where they don't make sense.


    And I agree with Mike particular on the part that I bolded above.
     
    Monica Shiralkar
    Ranch Hand
    Posts: 1415
    8
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:

    Monica Shiralkar wrote:Point is when to use abstract classes and when to instead use Java 8 Interfaces?


    My rule of thumb is to prefer interfaces over abstract classes. I can't remember the last time I've created an abstract class, honestly. If all you're interested in is the contract for behavior, which is most of the time anyway, then use interfaces. If you think there's something to gain by having a more concrete superclass-subclass relationship, then use abstract classes as your foundation. I think a class hierarchy imposes more restrictions on your design because you have to think about inheritance and the semantics of equals() and a bunch of other considerations that Joshua Bloch explains quite thoroughly in his book "Effective Java Programming".



    But if one should use Interfaces all the time then abstract classes also do exist for some reason.
     
    Mike Simmons
    Rancher
    Posts: 3507
    37
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    No one is saying use interfaces all the time.  Junilu and I are saying we recommend you prefer interfaces to abstract classes.  There is still room to use abstract methods for some things.

    Note that just because something exists, doesn't mean there's a good reason for it.  Some things might have been a good idea originally, but now there are better ways, so no longer a good idea.  Some things might have never been a good idea, but got into the language anyway.  Neither of these applies to abstract classes specifically, which can still be a good idea in at least some circumstances... but don't assume that just because a feature is there, it must be good for something.

     
    Bartender
    Posts: 2553
    120
    Google Web Toolkit Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:...But if one should use Interfaces all the time then abstract classes also do exist for some reason.



    I think the standard java tutorial provides a very good explaination: https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html

    The Java Tutorials wrote:Abstract Classes Compared to Interfaces
    Abstract classes are similar to interfaces. You cannot instantiate them, and they may contain a mix of methods declared with or without an implementation. However, with abstract classes, you can declare fields that are not static and final, and define public, protected, and private concrete methods. With interfaces, all fields are automatically public, static, and final, and all methods that you declare or define (as default methods) are public. In addition, you can extend only one class, whether or not it is abstract, whereas you can implement any number of interfaces.

    Which should you use, abstract classes or interfaces?

    Consider using abstract classes if any of these statements apply to your situation:

  • You want to share code among several closely related classes.
  • You expect that classes that extend your abstract class have many common methods or fields, or require access modifiers other than public (such as protected and private).
  • You want to declare non-static or non-final fields. This enables you to define methods that can access and modify the state of the object to which they belong.

  • Consider using interfaces if any of these statements apply to your situation:
  • You expect that unrelated classes would implement your interface. For example, the interfaces Comparable and Cloneable are implemented by many unrelated classes.
  • You want to specify the behavior of a particular data type, but not concerned about who implements its behavior.
  • You want to take advantage of multiple inheritance of type.
  •  
    Greenhorn
    Posts: 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    abstract class can have normal methods and abstract methods, interfaces  hava abstract method and static method
     
    Campbell Ritchie
    Marshal
    Posts: 68936
    275
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    beichen cao, welcome to the Ranch

    Interfaces, as stated before, can have default methods, at least since Java8.
     
    Mike Simmons
    Rancher
    Posts: 3507
    37
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Also, abstract classes can have static methods too.
     
    There's a city wid manhunt for this tiny ad:
    Two software engineers solve most of the world's problems in one K&R sized book
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
      Bookmark Topic Watch Topic
    • New Topic