-2

What is difference between following interface and abstract class:

 public interface MyInterface
{
  public int get1();
  public int get2();
  public int get3();
}

public abstract class MyAbstract
{
public abstract int get1();
public abstract int get2();
public abstract int get3();
}

Interviewer was not convinced with following answers, he wanted to hear something else:

  1. I have to extend MyAbstract and then I cannot have more extends, whereas in case of implementing MyInterface I am open to have inheritance.

  2. I have to provide implementation of all three methods if used "implements MyInterface", whereas in case of "extends MyAbstract" I am open to carry forward abstractness.

  3. Design perspective: All libraries work on interfaces not on abstract classes, it is good design practice to use interfaces so that at any time in future I can create any class (implements MyInterface) that can be used in some method of library. (basically same as point one)

What else there could be? I am not concerned with the variables in interface/abstract class etc. How to decide which one to use?

Amaresh
  • 331
  • 2
  • 5
  • 14
  • possible duplicate of [When to use abstract class or interface?](http://stackoverflow.com/questions/1221512/when-to-use-abstract-class-or-interface) – mprabhat May 22 '12 at 07:07
  • 3
    Your point #2 doesn't make sense (as written). A class can be declared to `implements MyInterface` and if it is also declared `abstract`, it does not need to implement any methods. Points 1 and 3 are good--any interviewer that doesn't like those reasons needs to explain himself. – Ted Hopp May 22 '12 at 07:09
  • 1
    Why has this been downvoted without even giving a reason in comments? I think this is a valid question. – Axel May 22 '12 at 07:11
  • @TedHopp : thanks very much. I didn't know that "implements MyInterface" can also carry abstractness. – Amaresh May 22 '12 at 07:17

3 Answers3

3

If the relationship between two classes is very definitely an "is-a" relationship, there might be a case for using an abstract class.

If you have "default behavior" common to all subclasses, then there's an even stronger case for using an abstract base class.

But in general, if you can use an interface, then you probably should use an interface.

IMHO...

paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • The more and more I use Java/C#-style OO, I am of the mind that abstract classes are merely archaic kludges that exist because no better way of implementation sharing was devised.. (okay, this isn't entirely true, but I prefer "interface contracts") –  May 22 '12 at 07:20
  • 1
    @pst - Abstract classes are extremely useful. You can factor out common code from related classes (don't repeat yourself), expressing [template methods](http://en.wikipedia.org/wiki/Template_method_pattern), and other handy things. You say that it "isn't entirely true" that they are "archaic kludges"; I say that it isn't true at all. – Ted Hopp May 22 '12 at 07:59
0

There is no sense in using an abstract class with all methods abstract - this is essentially an interface. If you have some common base logic(real code, not just abstract methods) then declare an abstract class, possibly implementing an interface.

Petar Minchev
  • 46,889
  • 11
  • 103
  • 119
0

I choose interface when there is no common code I should put in it. Only in case when there is something that can be shared via subclasses - yes I use abstract class (template patern).

And you always can have interface and than it's subclasses as abstract class.

Use interface at top level. Move there all methods that shoud be implemented. Program with interfaces not implementation. Implementations has more chanses to be changed, interfaces less.

alexey28
  • 5,170
  • 1
  • 20
  • 25