When to use an interface VS when to use abstract class

[Rohit Rai]

Hi,

I collected some points as to when to use interface and when to use abstract class.
Please check on them and add anymore that you know of.

1. Interface
1.a - when the design implementation may change frequently

2. Abstract Class
2.a - you want to provide a default behaviour
2.b - your abstract class may be changed - i.e we may later want to provide default concrete
methods so this can be inplemented without breaking the existing code

[Seetharaman Venkatasamy]

Yes,thats fine.

for your information: most of the time AbstractInterface[Skeletal Implementation Of interface] is useful

[jami siva]

Hi Seetharaman,

I didnt understand skeltonInteface , can you explain and give a sample Example is highly appreciate.


Thanks
Siva

[Campbell Ritchie]

A skeletal implementation is not an interface. It is an abstract class with very few methods implemented; I found a lecture note here, and you can probably find more on Google: skeletal implementation.

[jami siva]

Hi Campbell Ritchie,

Thanks for good document.

[Campbell Ritchie]

You're welcome

[Jim Hoglund]

Don't forget that a big disadvantage of an abstract
class is that it must be extended to be instantiated.
This locks out other possibly useful super classes.
Jim...

[Janeice DelVecchio]

Head First design patterns had a whole chapter on interface vs the abstract or super class and how to use a combination of both effectively. You should be able to find it on Amazon.

I think the chapter was for the "Strategy" pattern. You could probably search google for that, but I think the section I think about is just the setup for the pattern. I can't recommend HeadFirst books highly enough, so it's worth the money to buy it.

Realistically, there are uses for both... I think their phrase had something to do with composition versus inheritance.

I guess if I have more than one behavior to implement I should use interfaces. If ALL of the same type of object should use the behavior, I should use an abstract class.

Their situation had to do with ducks. If you create an abstract class with abstract method fly(), all ducks have to fly. What do you do about wooden ducks, rubber ducks, or decoy ducks?

That would be a good use for an interface (implements fly). Then you don't need to use it on the wooden, rubber, or decoys.

[Jim Hoglund]

Janeice : For your duck example, declaring fly() in an interface versus implementing
a version in an abstract class would not relax the flight requirement. On this point the
contracts are the same. In either case, a MethodNotSupported version of fly() would
be needed (implemented or overriden) to keep your decoys on the ground. Abstract
classes work well when some - but not all - behaviors are generic to all subclases.

Jim...

[Janeice DelVecchio]

For your duck example, declaring fly() in an interface versus implementing
a version in an abstract class would not relax the flight requirement.

Why not?

 abstract class Duck {
// all duck stuff here
}   

 class Mallard extends Duck implements Fly {
// mallard stuff
}   

 class Rubber extends Duck {
// rubber duckie stuff
}  

Now you have 2 ducks... one that implements fly, one that doesn't. If there was an abstract method in Duck, fly(), the rubber duck would either have to fly, or have code to make it not fly.

The strategy pattern takes it one step farther and uses composition for behaviors (HAS A QuackBehavior, HAS A SwimBehavior etc), but I think that is out of the scope of this thread. I was simply making the argument that either Abstract Classes, Interfaces, or both can be valid solutions to problems, and one is not necessarily better than another.

[Jim Hoglund]

interface Fly { 
   public Boolean fly(Bird b); 
}

Is defining a single method interface, named as its method, a recommended practice?

Jim...

[Janeice DelVecchio]

I don't think the fly interface would necessarily only have one attrubute.

This is a make believe scenario, but there could be methods takeOff(), land(), getTired()... et cetera. I simply used it as an example.

Really, if it was just the boolean attribute (flies or doesn't fly... true or false), you would keep the attribute in the member variables of the superclass. This is to seperate the flying methods of a duck (or you could, in an OO way, use it for all birds, save ostriches and penguins) from the non flying members of the duck hierarchy.

[Jim Hoglund]

. . Okay, now back to "When to use an interface VS when to use abstract class" which is a design
question. My comments have assumed a fixed set of static constants and method signatures (MyStuff).
Should I deliver "interface MyStuff" or "public abstract class MyStuff"? Of course it depends on some
other stuff. Thanks for the good discussion.

Jim...

[Janeice DelVecchio]

Jim Hoglund wrote: Of course it depends on some
other stuff. Thanks for the good discussion.

It does depend. You need to think, design wise, if the objects inheriting will ever not need that abstract method. If there is a time (like in the case of HeadFirst's non flying ducks) the abstract method is not needed, then an interface may be the way to go. This will eliminate the need for having to use workaround code for something the object doesn't do, because you can implement it on just the subclasses that need that behavior.

If EVERY subclass is ALWAYS going to have that behavior, you should probably go with the Abstract class. But if the behavior may need to be reused in other non related classes (like the fly interface and birds or bats), you might think of an interface.

Any of these involves a lot of code rework if you are going to need to change the behaviors frequently. If there are going to be code changes to one behavior, you will have to go into each subclass that uses that behavior, whether it's a concrete method or an interface implementation (thus messing with working code). In this case I would use composition and the strategy pattern.

... and you're welcome for the discussion

[Campbell Ritchie]

Janeice DelVecchio wrote: . . . If EVERY subclass is ALWAYS going to have that behavior, you should probably go with the Abstract class. . . .

If it always has the same ebhaviour,you can mark that method final.

[Janeice DelVecchio]

Can an abstract method BE final? Isn't an abstract method, by definition, needing to be overridden?

[Jim Hoglund]

An abstract class can contain implemented methods, as
well as unimplemented (abstract) method declarations.
The first can be declared final but the latter can not.

Jim...

[Janeice DelVecchio]

Hmph. That's what I thought. I suppose maybe Campbell thought I meant something else.

To clarify,

If the subclass ALWAYS needs to implement a behavior, the behavior should be part of the contract of the superclass. If a class should always provide its own code for the behavior, the method should be abstract. You can also provide a default behavior for the abstract class, and require the subclass to override it and make it specific.

The time to use abstract classes is when each subclass has the same behaviors. Otherwise, in my opinion, using an interface will ensure that only the subclasses that are supposed to have the behavior get it.

[Campbell Ritchie]

I thought that an abstract method doesn't specify any behaviour, so a method specifying behaviour must be implemented, so it's not abstract. Then you might mark it final, in which case that method has the same behaviour for ever in all subclasses.

No, you can't put abstract and final together on the same method nor on the same class (If I remember correctly).

[Janeice DelVecchio]

can't you do this?

 public abstract class Animal {
abstract void eat() {
// generic eating stuff
}   

 public class Giraffe extends Animal {
void eat() {
super.eat();
// tall eating stuff
}   

In this way, if it's possible, an abstract method might have real advantages over an interface.... but I guess in this example all animals eat with no exception so I would probably go with this setup anyway.

[Campbell Ritchie]

That won't compile unless you write Giraffe extends Animal. It will still not compile when you are calling an abstract method in the superclass. And remember an abstract method's body is a single semi-colon.

You have still not understood what I said. What I meant is that if you have an implemented method in a superclass, you can insist all subclasses use the same method unchanged by marking it final. As far as I know, you can have final methods which are implemented in an abstract class.

[Janeice DelVecchio]

Campbell Ritchie wrote:That won't compile unless you write Giraffe extends Animal. It will still not compile when you are calling an abstract method in the superclass. And remember an abstract method's body is a single semi-colon.

So if all animals eat, but differently, it's better to use abstract method, eat(), to force the next programmer to create a concrete method for his new animal.

You have still not understood what I said. What I meant is that if you have an implemented method in a superclass, you can insist all subclasses use the same method unchanged by marking it final. As far as I know, you can have final methods which are implemented in an abstract class.

I DID inderstand that, I just didn't understand how it worked with abstract methods. It won't work if you need to change the algorithm for a subclass; it will only work for methods that need/require no changing.

[Campbell Ritchie]

That is what I thought you meant when you said

ALWAYS going to have that behavior

then I suggested it might always have the same ebhaviour. I think we are thinking more-or-less the same things, just expressing them differently (and spelling them differently ).

[Janeice DelVecchio]

So you ASSUMED that because something has to have a behavior that it should be an identical behavior?

Nice.

[Campbell Ritchie]

No, I only thought it might have identical ebhaviour.