Using abstract class that implements interface

[Lew]

Simpler than that: a class C which extends Foo will fail to load if
Foo is an interface.

The salient point is that when one writes an API, which comprises every class
a programmer writes except the top-layer invocation class, one has to plan
ahead for the maintenance needs of that API. Once released into the wild, the
contract of the API is a commitment and further changes have to be made
responsibly. The decision to implement a type as an interface or a class will
have to be honored through the useful life of that type, or the cost of a
change must be incurred. By exposing the type as an interface, one keeps
certain options open.

As usual, and as pointed out by many in this forum, that doesn't mean *always*
select interfaces as the exposed type or *never* do so with abstract classes.
It does mean understand the tradeoffs, and that generally interfaces are the
safer, cleaner choice.

 

[Lew]

Had I not read the chapter, I would have taken the opposite assumption.  You
should assume it has meaning, since the author chose to make the statement. I
didn't think it would constitute fair use to quote the entire chapter, so I
restricted myself to quoting the talking points he introduced.  He does
explain what he means by that comment, I assure you, and it has meaning, I
assure you.

I am rather surprised that you'd assume that Joshua Bloch would make a
meaningless statement.  You might not agree with him, but he's a cogent writer
and in the habit of providing reasoned arguments with salient examples.  It
would make sense to conclude that his statements have meaning, though of
course you might conclude that he's not correct in his reasoning.

FWIW, it's a really good book and very relevant to the improvement of one's
skill as a Java programmer.  I highly recommend that you buy the book and read
it.  Of course, that will have the side effect of revealing to you what he
meant by that remark.

I went back to the book and did the research for you. Interfaces
allow functionality enhancements by allowing a class to implement a
new interface. They're safe because you would use composition to
implement the new interface, thus you don't have to change the
inheritance hierarchy, and you don't incur the exposure of
implementation that inheritance causes. They're powerful because you
can impose any supertype on a class that it needs, and you don't have
to give up on anything the class already implements, and you get to
protect implementation.

Thus the meaning of Joshua Bloch's assertion, "Interfaces enable safe,
powerful functionality enhancements," is that improvements to what a
class does are enabled with minimized risk and maximized utility by
the use of interfaces.

 

[Tom Anderson]

Simpler than that: a class C which extends Foo will fail to load if Foo
is an interface.

But what about classes which use Foo without extending it?

Say i start with this:

public abstract class Foo {
public abstract void method();
}

class FooImpl extends Foo {
public void method() {
System.out.println("running FooImpl.method");
}
}

public class FooClient {
public static void main(String... args) {
System.out.println("begun");
Foo foo = new FooImpl();
foo.method();
System.out.println("ended");
}
}

And then i change Foo and FooImpl to look like this:

public interface Foo {
public void method();
}

abstract class FooBase implements Foo {
public abstract void method();
}

class FooImpl extends FooBase {
public void method() {
System.out.println("running FooImpl.method");
}
}

*Without* recompiling FooClient?

The answer is that when i run FooClient, i get:

begun
Exception in thread "main" java.lang.IncompatibleClassChangeError
at FooClient.main(FooClient.java:6)

So FooClient loads okay, but the invocation of a method on a Foo fails,
because Foo was originally a class and is now an interface.

tom

 

[Roedy Green]

For me it looks logical...
Abstract class keep common part of internal implementation, but for
"external world" they are all instances of foo_interface... But - my
colleges - that come from JAVA programming - says - it is redundant
and interface is unnecessary... Is my implementation really something
fishy , or - it "does not break" rules og "JAVA world"???

What you did allows you to create a set of related implementations,
while leaving the door open to others to implement your interface from
scratch. You have the best of both worlds.

See http://mindprod.com/jgloss/interfacevsabstract.html

 

[Zuisman Moshe]

OK... I see - it is old dispute... I personally conclude to myself -
that my original decision was not something that contradict JAVA
"common sense" and - since - it seems to me personally more logical
and better suiting possible future life circle of this code - will
keep with it..
Thanks to all for your attention and wisdom