Abstract classes vs. Interfaces

[Dillinger4]

I have a question and any insight i could gain from you
java masters out there would be much appreacated.

I know that Java does not support multiple class inheritance but the language supports
multiple interface inheritance. For given reasons
i guess because multiple inheritance
adds alot of complexity to a language....
in my opinion.

I was thinking about when it would be more appropriate to use an interface
over an abstract class or visa versa.
I know that you define an interface
as part of a public API and then later
add a new method to the interface
you break any classes that implemented
the previous version of the interface.

so i thought a good idea
would be to create an interface
then create an abstract class
that implements that interface.

for instance:

public interface computations{
public double add(double x, double y);
public double multiply(double x, double y);
public double subtract(double x, double y);
}

public abstract class abstractcomputation implements computations{
protected double x,y;

public double add(double x, double y) {this.x = x + x; this.y = y + y; }

public double multiply(double x, double y) { this.x = x * x; this.y = y * y; }

public double subtract(double x, double y) { this.x = x - x; this.y = y - y; }

}

so if a new method is later add to
the interface and implementation
is not provided for the new method the
class is already abstract to begin with.

1.) can this be done?

2.) has anyone ever used any technique simliar to this in there code?

thanks all........

[billrogers]

I think this should work although I have never really done this. But the real question is why would you want to?

It doesnt really gain you anything, all you would really need is the abstract class. Say the interface has the method divide, the abstract class stills needs to have that method defined since it is implementing the interface.

Even though the class is abstract I believe it still needs to implement all the methods of the interface.
Note*: Not 100% sure on my answer since having not done it before.

[Dillinger4]

quote:

"Even though the class is abstract I believe it still needs to implement all the methods of the interface."

I dont think that i necessarily true since the class is already abstract itself. So say if a method it later added
to the interface and no implmentation is defind
for that method in the abstract class is still abstract.
Would that be right?

[Dillinger4]

Sorry i should have just added this to the last post.
=C(

I was just trying to understand the use of interfaces as a soultion to multiple class inheritance, which Sun says
is the main point of using an interface.

quote: Java in a Nutshell / O'Rielly: " Java's
soultion to this problem is called an interface. Although a java class can extend only a single superclass, it can implement any number of interfaces".

It just seems long winded say if a class wants certain methods from one interface and certain methods from another, implmentation must be provided to all the methods even the ones not needed.

[VirtuallyVB]

I agree with bill, that you don't gain anything.

You'll still only be able to extend the "class abstractcomputation" with single inheritance, not multiple inheritance. You know that.

Any class using a single or multiple implementation of "interface computations" will loose (or rather, never gain) the implementation that is in class abstractcomputation.

I don't want to discourage you. You may be onto something I missed.

[Dillinger4]

yes i guess you are right VirtuallyVB. Any class which implements computations would never gain the implementation that is in class abstractcomputation.

Im just trying to understand what the author is getting at. He says "If a interface is
part of a public API and a
method is later added to
the interface you break
any classes that implemented
the previous version of the interface."

ok that is understandable but
he seem to be saying that
defining an abstract class
that implements an interface
would solve that problem.

quote:

"If you use an abstract class
however you can safely add
nonabstract methods to that class
with out requiring modifications
to existing classes that extend the
abstract class"

so what is he trying to get at? Im not quite sure.

[VirtuallyVB]

Okay now, that quote has the key, "nonabstract methods". Since the author means to add non-abstract methods to the already abstract class, any subclass will inherit those non-abstract methods without having to provide implementations because they are already provided (unless they wanted to override them).

Implementing an interface would require providing the code in the method body (whether or not the interface is the old or new version, but a new interface with additional methods would "break" the subclasses that used the old interface). By "break", he means that the subclasses would need to be edited and recompiled to support the new methods.