when to use interface and when abstract class

[subho saha]

My question is, in designing a project how do we know in a particular scenario wheather to use interface or abstract class. or specifically when do i use abstract class and when an interface?

[Timmy Marks]

The first consideration would probably be:

must I derive from a specific class (for example Applet) --> use Interface

This is the only hard and fast rule to answer the question, but a google search of "interface vs abstract" (without the quotes) returns 1.3 million results. I think at least one of them contains true information instead of porn!

As a matter of fact, this is one of the top 10!
[ June 15, 2005: Message edited by: Timmy Marks ]

[Kai Witte]

hello,

some poeple say that an abstract class should be used when it is important to provide some functionality that all subclasses will need.

I am totally against this design. Generally it is a bad design. If there are common features that many implementing classes of an interface would need, then make an abstract class that implements your interface. An example for this design is java.util.List and java.util.AbstractList. With this approach clients of your API can still make their own interfaces which extend your interface. If you would only provide an abstract class that would not be possible. This is only one of many reasons why the strict "abstract class" approach is wrong. I don't see any exceptional situations where it would be good to have an abstract class that does not implement an interface.

There are also people who say that abstract classes should not be used at all.

Conan

[Ilja Preuss]

http://faq.javaranch.com/view?InterfaceVsAbstractClass

[Ilja Preuss]

Originally posted by Conan Elvitaro:
If there are common features that many implementing classes of an interface would need, then make an abstract class that implements your interface. An example for this design is java.util.List and java.util.AbstractList. With this approach clients of your API can still make their own interfaces which extend your interface. If you would only provide an abstract class that would not be possible. This is only one of many reasons why the strict "abstract class" approach is wrong. I don't see any exceptional situations where it would be good to have an abstract class that does not implement an interface.

In the situation where you have full control over all clients of a class (that is, you aren't publishing an API to another team or something), an interface can easily be introduced when you need it - especially with todays powerfull refactoring tools.

In those situations, which I find to be most common, introducing an interface before you actually *need* one adds to the complexity of the code without giving you any benefits, or so it seems to me.

There are also people who say that abstract classes should not be used at all.

With what justification? Wouldn't that hold you from using such powerfull design patterns like Template Method or Factory Method?
[ June 16, 2005: Message edited by: Ilja Preuss ]

[Kai Witte]

hello,

Originally posted by Ilja Preuss:
In the situation where you have full control over all clients of a class (that is, you aren't publishing an API to another team or something), an interface can easily be introduced when you need it - especially with todays powerfull refactoring tools.

it does not make much difference wether or not you are your own client, and being the client of your own API does not justify the violation of fundamental OOD principles*. The only difference is that the damage done by a poor design is not as high if you are your own client, because you can still change your interface (e. g. change a return type from an abstract class type to an interface type later). I agree that a broken design can easily be fixed with tools every developer has (usually the IDE in this case).

Originally posted by Ilja Preuss:
In those situations, which I find to be most common, introducing an interface before you actually *need* one adds to the complexity of the code without giving you any benefits, or so it seems to me.

The fear of adding classes or interfaces is dangerous and has destroyed more than just one project. I do not see any negative impact when every type (declaration, return type, method parameter) is an interface type.

Originally posted by Ilja Preuss:
With what justification? Wouldn't that hold you from using such powerfull design patterns like Template Method or Factory Method?

To provide a complete answer to the original question it seemed right to mention all serious opinions that are out there (that I know of). However, it is not my opinion and I can not justify it.

Conan

* The principle violated here is "Program to an interface, not an implementation." If you use an abstract class (which naturally has some non-abstract methods, otherwise you would use an interface) as a type, you are programming to a particular implementation. All arguments that apply for this fundamental principle in general also apply in this case.

[Tony Morris]

...introducing an interface before you actually *need* one adds to the complexity of the code without giving you any benefits.

LOL!
Oh wait, I maintain code by people who think like that.

[Ilja Preuss]

Originally posted by Tony Morris:

LOL!
Oh wait, I maintain code by people who think like that.

With all due respect, I don't think you really know how I think.

If your perspective differs from mine (which wouldn't surprise me), I'd be happy to discuss this - I'd expect to learn something from it and that's what I'm here for. As it stands above, it isn't helpful at any rate, and actually rather a little bit insulting...

[Ilja Preuss]

Originally posted by Conan Elvitaro:
it does not make much difference wether or not you are your own client

To me, it does *much* difference! Flexibility often comes at the price of complexity. If I the clients are under my full control, I can wait adding the flexibility until I really need it. If the clients aren't under my control, I don't have that luxury.

being the client of your own API does not justify the violation of fundamental OOD principles*.

To me, the principles aren't hard and fast rules. There always is a balance, and that balance needs to be considered in each case to apply the principles in a usefull way.

The only difference is that the damage done by a poor design is not as high if you are your own client, because you can still change your interface (e. g. change a return type from an abstract class type to an interface type later). I agree that a broken design can easily be fixed with tools every developer has (usually the IDE in this case).

If a design easily can be adjusted to new needs, why would you call it broken?

The fear of adding classes or interfaces is dangerous and has destroyed more than just one project. I do not see any negative impact when every type (declaration, return type, method parameter) is an interface type.

I agree that fear is bad. What one needs is carefull consideration of the actual situation at hand.

Having an interface additionally to a class adds the overhead of having to maintain that interface. If you want to change an operation on the type, you have one more place to change. If the interface doesn't solve a design problem, that overhead isn't warranted.

To provide a complete answer to the original question it seemed right to mention all serious opinions that are out there (that I know of). However, it is not my opinion and I can not justify it.

OK.

The principle violated here is "Program to an interface, not an implementation." If you use an abstract class (which naturally has some non-abstract methods, otherwise you would use an interface) as a type, you are programming to a particular implementation. All arguments that apply for this fundamental principle in general also apply in this case.

True. But sometimes when I use an abstract class, I really just do that to reuse some code - I'm actually not interested in having the concrete classes being interchangeable polymorphically. In such a case, an interface sounds like overkill to me.

[Tony Morris]

No offence intended, mostly in jest. I apologise for the very obvious way it could have had another context applied. In any case, I only just recently was told by a colleague to "reduce types because it simplifies the design", which kind of irked me a bit, because that is an elementary broken train of thought, and I have to deal with these kind of people far too often.

Without restating what is already very well documented, I refer you to the following: http://c2.com/cgi-bin/wiki?FearOfAddingClasses
You should also note that thinking in terms of "introducing an interface before you actually *need* one" is quite broken on another elementary level, but I suspect I'm putting my foot into a very low quality debate.

[Ilja Preuss]

Originally posted by Tony Morris:
No offence intended, mostly in jest. I apologise for the very obvious way it could have had another context applied.

Apology accepted.

In any case, I only just recently was told by a colleague to "reduce types because it simplifies the design", which kind of irked me a bit, because that is an elementary broken train of thought, and I have to deal with these kind of people far too often.

Without restating what is already very well documented, I refer you to the following: http://c2.com/cgi-bin/wiki?FearOfAddingClasses

Very good link I actually refer other people to quite often. I'm actually using interfaces quite a lot and like to have many small, very focussed classes.

Do you agree that just blindly adding interfaces for every (abstract) class doesn't necessarily simplify a design either?

You should also note that thinking in terms of "introducing an interface before you actually *need* one" is quite broken on another elementary level, but I suspect I'm putting my foot into a very low quality debate.

I'm not sure I'm following you. I would be gratefull if you could elaborate on it. I think we can still let this be a high quality, respectful discussion instead of a low quality debate....