• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When to use an interface VS when to use abstract class

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes,thats fine.

for your information: most of the time AbstractInterface[Skeletal Implementation Of interface] is useful
 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Seetharaman,

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


Thanks
Siva
 
Marshal
Posts: 79260
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Campbell Ritchie,

Thanks for good document.
 
Campbell Ritchie
Marshal
Posts: 79260
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome
 
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?







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
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

Jim...
 
Janeice DelVecchio
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
. . 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
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79260
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can an abstract method BE final? Isn't an abstract method, by definition, needing to be overridden?
 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79260
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
can't you do this?





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
Marshal
Posts: 79260
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79260
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1849
15
Eclipse IDE Spring VI Editor Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So you ASSUMED that because something has to have a behavior that it should be an identical behavior?

Nice.
 
Campbell Ritchie
Marshal
Posts: 79260
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, I only thought it might have identical ebhaviour.
 
reply
    Bookmark Topic Watch Topic
  • New Topic