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

[Monica Shiralkar]

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

[Campbell Ritchie]

Try running this code:-

public interface Foo
{
    private int i;

   public Foo(int i)
   {
      this.i = i;
   }

   default public String toString()
   {
      return this.getClass().getName() + " " + i;
   }
}

[Monica Shiralkar]

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]

Which version of Java® are you using?
What happened when you changed interface at the beginning to abstract class?

[Monica Shiralkar]

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]

You are only allowed default methods in interfaces.

[Monica Shiralkar]

But the code which you pasted has default method .I just created interface with that name Foo and pasted the same code.

[Stephan van Hulst]

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]

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]

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]

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]

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]

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]

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]

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]

have more in common than you think

OK but lesser similarity than in case of classes implementing abstract classes.?

[Stephan van Hulst]

Again, I don't see how you draw that conclusion.

[Junilu Lacar]

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.

[Mike Simmons]

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]

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]

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]

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]

Point is when to use abstract classes and when to instead use Java 8 Interfaces?

[Campbell Ritchie]

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]

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]

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]

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]

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]

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.

[salvin francis]

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.

[beichen cao]

abstract class can have normal methods and abstract methods, interfaces  hava abstract method and static method

[Campbell Ritchie]

beichen cao, welcome to the Ranch

Interfaces, as stated before, can have default methods, at least since Java8.

[Mike Simmons]

Also, abstract classes can have static methods too.

[Monica Shiralkar]

Mike Simmons wrote: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.  

Thanks. This is one such case where one would go for abstract class and not Java 8 Interface.

[Monica Shiralkar]

Mike Simmons wrote: 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.

Thanks. This is a good point.

[Monica Shiralkar]

beichen cao wrote:abstract class can have normal methods and abstract methods, interfaces  hava abstract method and static method

Thanks. Yes. And we cannot call the default method a 'normal method' since it always has to be public.

[Monica Shiralkar]

So although default method is a concrete method ,it has to be compulsorily public and non static.

[Campbell Ritchie]

When did you last look at the JLS? Can you have private default methods now?

[Monica Shiralkar]

Campbell Ritchie wrote:When did you last look at the JLS? Can you have private default methods now?

Thanks. I was wrong. Although when Default methods were introduced in Java 8, those had to be public, the Default methods can be private from Java 9 onwards.  Also, now interfaces can have static methods too. So , the difference between abstract classes and interfaces now is a lot narrower than what it was say during earlier versions of Java. I am trying to find a simple use case to understand this difference.

[Monica Shiralkar]

salvin francis wrote:

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.

Thanks