Abstract Class vs. Interface

[Mathew Kuruvilla]

What is the difference? I can find the answer to this one, but posted it here for a quick answer.
Also what is the difference between an abstraction and encapsulation? Huh??
These are questions for a java test that I took today :-)

[Kumar Kausikasa]

Hi,
Abstract classes are permitted to contain implementations of some methods while interfaces are not.
But declaring interfaces, you are giving the complete responsibility to the programmer who is implementing it.
But if you want the classes extending the abstract should have some default functionality, you can declare them in one of the methods. Then all the classes extending the abstract class will have them.
In interfaces you have implement all the methods of interface or atleast declare them , with abstract classes, there is no such need.
"These are the two mechanisms for defining a type that permits multiple implementations" -- Joshua Bloch.
HTH
praveen.

[Thillai Sakthi]

Thanks Praveen.
One other thing I would like to add is, since you cannot extend more than one class, you can take advantage of implementing more than one interface.
For example, if you class needs to have some methods from Thread Class but you also need to extend one of your own classes, you could not do it. The work around would be to implement Runnable interface and extend your own class as above.

[Ilja Preuss]

In fact, the only reason for the existence of interfaces in the Java language is the absence of multiple inheritance for classes. If Java had MI for classes, interfaces would be redundant, because of being equivalent to fully abstract classes.

[Philip Shanks]

Originally posted by Ilja Preuss:
In fact, the only reason for the existence of interfaces in the Java language is the absence of multiple inheritance for classes. If Java had MI for classes, interfaces would be redundant, because of being equivalent to fully abstract classes.

I think this argument is starting to show its age. I believe that Java developers use the interface as more than just a workaround for not having multiple inheritance. Consider the "Serializable" interface. It is a marker to distinguish one type of class from another, but does nothing to specify implementation details.
Also, consider the naming convention: abstract class names are similar to concrete class names -- both are nouns, while interface names should be adjectives like Runnable, Serializable (whether they dictate implementation or not).
To me, this points to more than just a workaround for a shortcoming in the language (which I'm not so sure it is a shortcoming), but rather an implementation of a style of OO design.
So, yes the interface can be used to emulate multiple inheritance, but it can also be used for other purposes as well.

[B Hayes]

I just read an excellent article here:
http://www.javaworld.com/javaworld/jw-09-2001/jw-0921-interface.html
Check it out.

[Thomas Paul]

The main purpose of making a class abstract is to prevent the class from being instantiated.

[Pavel Halas]

Originally posted by Ilja Preuss:
In fact, the only reason for the existence of interfaces in the Java language is the absence of multiple inheritance for classes. If Java had MI for classes, interfaces would be redundant, because of being equivalent to fully abstract classes.

Sorry, I must strickly disagree. Philip Shanks showed it up...
But there's no absence at all. What are you saying about this?

public class SomeObject {
  First first;
  Second second;
  public SomeObject() {
    first = new First();
    second = new Second();
  }
  private class First extends FirstObject {
    ...
  }
  private class Second extends SecondObject {
    ...
  }
}

[Jim Yingst]

[Phil]: Consider the "Serializable" interface. It is a marker to distinguish one type of class from another, but does nothing to specify implementation details.
But Ilja's point is that it would be entirely possible to achieve the same effect with an abstract class, if multiple inheritance were allowed:

public abstract class Serializable {}

Also, consider the naming convention: abstract class names are similar to concrete class names -- both are nouns, while interface names should be adjectives like Runnable, Serializable (whether they dictate implementation or not).
That indicates a certain outlook on how abstract classes an interfaces are typically expected to be used, true. But if interfaces did not exist and multiple inheritance were allowed, the same usages could still be performed with abstract classes, and you could have something like

public abstract class Runnable {
    public abstract void run();
}

or the previously mentioned Serializable.
Conceptually, interfaces have been useful in forcing people to break away from overuse of implemenation inheritance. Using abstract classes instead may make it too easy to overuse again. But that could be overcome with eduaction. And sometimes implemenation inheritance is the way to go, and Java's lack of multiple implemenation inheritance can be a bit inconvenient.

[Pavel]: But there's no absence at all. What are you saying about this?
[code omitted]
That's not multiple inheritance, though it is similar and in some cases may even be preferable. Note that SomeObject is not a FirstObject or a SecondObject. If you pass a SomeObject to a method that expects a FirstObject as a parameter, it will fail. You may work around this in several ways (create a new interface, or expose the FirstObject aspect with a new method). But it's not as easy as simply being able to say
class SomeObject extends FirstObject, SecondObject {}
I'm not arguing that Java needs multiple inheritance - just that the technique you're suggesting is not multiple inheritance.

[Pavel Halas]

OK. You've said we do not need interface if we had the multiple inheritance. But I doubt.
We use interface to force some methods and when we see similarities in different classes. Let's talk about the second itemt.
The abstract class could not be construct every time....

It could not be possible at all: We're using inheritance from library classes.

Could be difficult: The parent would be evidently artificial.

[Jim Yingst]

Could you provide an example for either of these points? I'm not sure what you mean. Thanks...

[Ilja Preuss]

Pavel, I don't follow you.
What does an Interface have a purely abstract class doesn't have?

[Pavel Halas]

Ones more with explanation.
The abstract class could not be construct every time....

It could not be possible at all: We're using inheritance from library classes.
We have a class named MyApplet (for example). It must be extended from Applet. In Java you can't use multiple inheritance so you can't force implemetation of a methods from abstract class.

Could be difficult: The parent would be evidently artificial.
Capturing similarities between unrelated classes without artificially forcing a class relationship.

We should consider the rigth OO design.

What does an Interface have a purely abstract class doesn't have?

No, that's not good question. Abstract class is fairly the same but with another use. There are items above that explain it...
This conversation gets from developing to philosophy. And the truth is relative ;-).
In fine we're all on the same boat. We develop in Java, and Sun decided to "substitute" problematic multiple inheritance with interface. But another point is that interface has its problems too. Consider two interfaces with the same method that differs only in return type and the class that implements them both...

[Joel McNary]

Originally posted by Pavel Halas:
In fine we're all on the same boat. We develop in Java, and Sun decided to "substitute" problematic multiple inheritance with interface. But another point is that interface has its problems too. Consider two interfaces with the same method that differs only in return type and the class that implements them both...

I believe that C# nicely solved this problem by allowing you to declare which interface's method you were implementing. Thus, you could have a class that implemented both interfaces. The class would have two methods with the same name, but the signatures would be different -- one would be signed as being for InterfaceA and the other for InterfaceB (essentially, you have just overloaded the method).
Granted, I've never used C#, but I seem to recall Thomas Paul saying something along these lines....
On the whole, I would rather have interfaces over multple inheritance. I was never really comfortable with multiple inheritance, and my two favourite languages, Obejctive-C and Java, do not have it (but they both have interfaces). On the whole, it's enought to make one go learn Smalltalk...

[Ilja Preuss]

Originally posted by Pavel Halas:
It could not be possible at all: We're using inheritance from library classes.
We have a class named MyApplet (for example). It must be extended from Applet. In Java you can't use multiple inheritance so you can't force implemetation of a methods from abstract class.

But that's exactly the point: if Java *had* MI, it wouldn't need interfaces.

Could be difficult: The parent would be evidently artificial.
Capturing similarities between unrelated classes without artificially forcing a class relationship.
We should consider the rigth OO design.

I don't understand this. What's the difference between
class MyClass extends OtherClass implements List
and
class MyClass extends OtherClass, List
with List being a purely abstract class in the latter case???

No, that's not good question. Abstract class is fairly the same but with another use.

I still think that a purely abstract class is *exactly* the same (besides MI) and could be used exactly as interfaces are used.

[Joel McNary]

Originally posted by Ilja Preuss:

I still think that a purely abstract class is *exactly* the same (besides MI) and could be used exactly as interfaces are used.

Not exactly. See this thread about the confusion that multiple-inherited objects can cause; particularily note Michael Morris's post about schizophrenic classes. Granted, no real-world program would ever do anything as obvious as the CatDog, but sometimes it isn't so obvious...

[Jim Yingst]

No, I'm still with Ilja here. I don't see what the problem is in Michael's example. The only potential I see for schizophrenic behavior is if Dog and Cat both implement (or at least declare and describe behavior for) two methods with the same signature. This is possible with interfaces too though:

public interface Animal {
    void eat(Object obj);
}
public interface Dog extends Animal {
    /**
     * @param obj must be instance of DogFood 
     * @throws IllegalArgumentException if obj not DogFood
     */
    void eat(Object obj);
}
public interface Cat {
    /**
     * @param obj must be instance of CatFood 
     * @throws IllegalArgumentException if obj not CatFood
     */
    void eat(Object obj);
}
public interface CatDog extends Dog, Cat {
    /**
     *  @param obj doesn't matter; cant eat it
     *  @throws IllegalArgumentException always
     */
    void eat(Object obj);
}

Or a simpler example:

interface A { 
    void foo();
}
interface B() {
    int foo();
}
interface AB extends A, B {
    // impossible; no way to implement foo() with two different return types
}

As for Michael's statement that a CatDog would consist of two Objects, two Animals, a Cat and a Dog - ummm, not the way I'd describe it, no. Maybe this description makes sense in C++ or another language. But in Java a Dog would be only one object - a Dog, which is also an Animal, which is also an Object. We don't count that as 3 objects, just 1. Why would multiple inheritance change that?
So, I agree with Ilja that anything that can be done with interfaces could also be done with purely abstract classes - if Java allowed multiple inheritance. Yes, there are problems associated with multiple inheritance, and I'm not arguing that Java should allow it. The chance of schizophrenic behavior being a problem does increase once you start inheriting multiple implementations of method with the same signature. But that has nothing to do with the purely abstract classes Ilja was talking about - they're no more or less safe than Java interfaces in this respect. Except of course that Java doesn't allow multiple inheritance of classes - but that was the point of this discussion: what if Java did? Ilja is correct, there would be no need for interfaces; purely abstract classes could do the same thing.

[Thomas Paul]

Originally posted by Joel McNary:
I believe that C# nicely solved this problem by allowing you to declare which interface's method you were implementing. Thus, you could have a class that implemented both interfaces. The class would have two methods with the same name, but the signatures would be different -- one would be signed as being for InterfaceA and the other for InterfaceB (essentially, you have just overloaded the method).
Granted, I've never used C#, but I seem to recall Thomas Paul saying something along these lines....

Yep, this solves the problem of implementing two interfaces that have method signatures that differ only by return value. In Java, you can't have a class that implements both interfaces. In C# you can.

[Mathew Kuruvilla]

Am revisiting this thread after a very long time. So what was the final conclusion? That is, if java had multiple inheritance, would interfaces be redundant? In other words, can everything that is possible by multiple inheritance be performed with interfaces?

Somebody talked about schizophrenic behavior that is caused by multiple inheritance. Since Java does not allow multiple implementations of the method 'foo' when two different interfaces having 'foo' in them are implemented by a class, does that mean that schizophrenic behaviour is effectively blocked out by the design of Java. And C# allows this, does it allows schizophrenic code?