Forums Register Login

abstract or interface - which one to choose?

+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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)
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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.

 
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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.
Climb the rope! CLIMB THE ROPE! You too tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1222 times.
Similar Threads
Interface & Abstract class
Abstract Classes Vs Interfaces
Abstract vs. Interfaces
Abstract class and interface
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 07:40:40.