• 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

abstract or interface - which one to choose?

 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know the difference between an abstract class and an Interface. Both containts abstract methods which should be implemented by the inheriting class and abstrace class have non abstract methods also.

Additionally interface gives a solution to multiple inheritance problem in Java. Apart from the above scenarios asked to write a abstract or an interface which one should I choose? and what should be the constraints I should see first?

Thanks in advance,
Jerry.
 
Ranch Hand
Posts: 425
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am sure this question must be answered more than any other question in Java and the answer really depends on the application you are developing. However interface will be preferred for couple of reasons
- It's simple
- It models only behavior (unlike abstract class which can model both state and behavior)
- You need interfaces (not abstract class) if your objects are invoked over RMI.
- Design patterns mostly suggest to program to Interface

Abstract class mostly helps in code reuse or avoiding code duplication by extracting them in one class. The cost of implementing one interface and extending an abstract class will be same as both will use one vptr* and vtable (if you exclude the object size)
 
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An interface is better than an abstract class because it doesn't promote the yo-yo problem. Suppose you have class A extends B, which extends C, which extends D. D implements a method, x(), which calls an abstract method, y(), which is implemented in B. The implementation in B calls a method, z(), which is implemented in C, which calls t(), which is implemented in A.

Without behavioural inheritance (inheriting from a class), this situation simply would not arise. Unlike in C++, it's impossible in Java to inherit from a class without ending up with some of the superclass' behaviour (even if that's just the constructor).

You can think of an interface as just being something there to persuade the compiler that you know what you're doing, as I mention in these lecture notes:

http://docs.google.com/Doc?id=dx5mfkq_77fd65h3
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This isn't much of an answer, but in most problem domains, an interface is more common than an abstract class. Just look over a typical API JavaDoc - you'll see many more interfaces than abstract classes.

-Cameron McKenzie
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
http://faq.javaranch.com/view?InterfaceVsAbstractClass
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just to say "interfaces are better than abstract classes", without analyzing the particular context, would be silly.

For example, if your abstract class would have only a few abstract methods and many other non-abstract implemented methods, would you convert it to an interface? Probably not, that would lead to a lot of repeated code.
 
Jeff Mayer
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeff Mayer:
Just to say "interfaces are better than abstract classes", without analyzing the particular context, would be silly.

For example, if your abstract class would have only a few abstract methods and many other non-abstract, would you convert it to an interface? Probably not, that would lead to a lot of repeated code.

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a good discussion related to this at:
Artima
In this discussion Eric Gamma says, "Once you depend on interfaces only, you're decoupled from the implementation. That means the implementation can vary, and that's a healthy dependency relationship. For example, for testing purposes you can replace a heavy database implementation with a lighter-weight mock implementation. Fortunately, with today's refactoring support you no longer have to come up with an interface up front. You can distill an interface from a concrete class once you have the full insights into a problem. The intended interface is just one 'extract interface' refactoring away.

So this approach gives you flexibility, but it also separates the really valuable part, the design, from the implementation, which allows clients to be decoupled from the implementation. One question is whether you should always use a Java interfaces for that. An abstract class is good as well. In fact, an abstract class gives you more flexibility when it comes to evolution. You can add new behavior without breaking clients."

There is a lot more in the article, so I would recommend reading the full thing.
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Just to say "interfaces are better than abstract classes", without analyzing the particular context, would be silly.



No it wouldn't. It's a generalisation. Generalisations don't need particular contexts. One can say "if statements are better than gotos" in the same way.

Further, I recognise 'would be silly' as an ad hominem argument, and suggest avoiding those.

For example, if your abstract class would have only a few abstract methods and many other non-abstract implemented methods, would you convert it to an interface? Probably not, that would lead to a lot of repeated code.



No, it wouldn't. There are other ways of getting rid of code redundancy than whacking stuff into a common superclass. I haven't written a common superclass for years, and I really haven't missed them. And I don't end up with repeated code because of it.

Provide some code that you think benefits from using abstract classes, and I'll happily refactor it.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic