Using abstract class that implements interface

[Zuisman Moshe]

Hi dear All...
It is a kind of philosophical question (since finally - it works bot
ways)... But - since I am quite new in JAVA (I comes from PERL and
shell programming) - it is interesting for me...
So - story is this:
I have family of classes - that share same interface (methods - that
they declare to "external world" as public) - "foo_interface"... They
also have large part of internal implementation - shared by all of
them ( attributes and protected methods)... So - I defined also
foo_interface and foo_abstract_class - that implements it... All
"real" classes - inherit from this foo_abstract_class... When I keep
references in arrays of objects , and serialize/desirealize them - I
keep them as instances of foo_interface... 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"???

 

[Lew]

It is a kind of philosophical question (since finally - it works bot
ways)... But - since I am quite new in JAVA [sic] (I comes from PERL and
shell programming) - it is interesting for me...
So - story is this:
I have family of classes - that share same interface (methods - that
they declare to "external world" as public) - "foo_interface"... They

The Java naming convention
<http://java.sun.com/docs/codeconv/index.html>
for type names is to use an upper-case first letter, camel case (each word
portion also begins with an upper-case letter) and no underscores. It's also
rather bad practice to include "interface" in interface names or "class" in
class names. They are *type* names first and foremost and should be built
accordingly.

also have large part of internal implementation - shared by all of
them ( attributes and protected methods)... So - I defined also
foo_interface and foo_abstract_class - that implements it... All
"real" classes - inherit from this foo_abstract_class... When I keep
references in arrays of objects , and serialize/desirealize them - I
keep them as instances of foo_interface... 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

All perfectly legitimate, idiomatic and beneficial.

colle[a]ges - that come from JAVA [sic] programming - says - it is redundant
and interface is unnecessary... Is my implementation really something
fishy , or - it "does not break" rules og "JAVA [sic] world"???

Your colleagues are wrong. You should publish the interface name, not the
class name; that is the best practice. That way if you need to create an
additional inheritance tree for the interface or directly implement the
interface in a concrete class, you don't break client code.

Point your colleagues to the many articles about "programming to the
interface", a best practice in O-O programming, and Java programming in
particular. They need to study more, and pay more attention to your wisdom.

 

[Tom Anderson]

It is a kind of philosophical question (since finally - it works bot
ways)... But - since I am quite new in JAVA (I comes from PERL and
shell programming) - it is interesting for me...
So - story is this:
I have family of classes - that share same interface (methods - that
they declare to "external world" as public) - "foo_interface"... They
also have large part of internal implementation - shared by all of
them ( attributes and protected methods)... So - I defined also
foo_interface and foo_abstract_class - that implements it... All
"real" classes - inherit from this foo_abstract_class... When I keep
references in arrays of objects , and serialize/desirealize them - I
keep them as instances of foo_interface... 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"???

It's strictly a matter of taste and/or appropriateness to the situation.
Both are legal and defensible.

The interface + abstract base class pattern is quite common - the obvious
example that springs to mind is the set of pairings of List/AbstractList,
Map/AbstractMap, etc in the collections framework. However, it does mean a
little extra complexity, and the benefits may not justify that in all
situations.

Personally, i'd start with just the abstract base class, doing double duty
as an interface definition and a home for common methods, and later on, if
i needed to, i'd refactor to separate the interface and implementation.
There's just no point building in more complexity than you need at the
start.

tom

 

[Tom Anderson]

It is a kind of philosophical question (since finally - it works bot
ways)... But - since I am quite new in JAVA [sic] (I comes from PERL and
shell programming) - it is interesting for me...
So - story is this:
I have family of classes - that share same interface (methods - that
they declare to "external world" as public) - "foo_interface"... They
also have large part of internal implementation - shared by all of
them ( attributes and protected methods)... So - I defined also
foo_interface and foo_abstract_class - that implements it... All
"real" classes - inherit from this foo_abstract_class... When I keep
references in arrays of objects , and serialize/desirealize them - I
keep them as instances of foo_interface... 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

All perfectly legitimate, idiomatic and beneficial.

colle[a]ges - that come from JAVA [sic] programming - says - it is
redundant
and interface is unnecessary... Is my implementation really something
fishy , or - it "does not break" rules og "JAVA [sic] world"???

Your colleagues are wrong. You should publish the interface name, not the
class name; that is the best practice. That way if you need to create an
additional inheritance tree for the interface or directly implement the
interface in a concrete class, you don't break client code.

Point your colleagues to the many articles about "programming to the
interface", a best practice in O-O programming, and Java programming in
particular. They need to study more, and pay more attention to your
wisdom.

'Programming to an interface' does *not* refer to the syntactic construct
of an interface, but the semantic idea of a set of defined, public
methods. What in Smalltalk would be called a 'protocol'. An abstract base
class can define an interface for this purpose just as well as an
interface (IYSWIM).

tom

 

[Mark Space]

"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"???

I disagree with your colleges. Using interfaces is fine, even
considered desirable. I can't understand why anyone would want to use an
abstract base class as a type instead of an interface. That borders on
naive, or worse.

The only thing I do urge you to do is to use Java naming conventions.

public interface Foo {....}
public abstract class AbstractFoo implements Foo {....}

These are much better names "Java world" for classes. I know it can be
tough when you have a lot of experience with other conventions, but
you'll be happier in the long run if you try to write Java code with the
recommended naming conventions. I can't think of anyone who does not
follow these rules.

<http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html>

 

[Arne Vajhøj]

It is a kind of philosophical question (since finally - it works bot
ways)... But - since I am quite new in JAVA [sic] (I comes from PERL
and
shell programming) - it is interesting for me...
So - story is this:
I have family of classes - that share same interface (methods - that
they declare to "external world" as public) - "foo_interface"... They
also have large part of internal implementation - shared by all of
them ( attributes and protected methods)... So - I defined also
foo_interface and foo_abstract_class - that implements it... All
"real" classes - inherit from this foo_abstract_class... When I keep
references in arrays of objects , and serialize/desirealize them - I
keep them as instances of foo_interface... 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

All perfectly legitimate, idiomatic and beneficial.

colle[a]ges - that come from JAVA [sic] programming - says - it is
redundant
and interface is unnecessary... Is my implementation really something
fishy , or - it "does not break" rules og "JAVA [sic] world"???

Your colleagues are wrong. You should publish the interface name, not
the class name; that is the best practice. That way if you need to
create an additional inheritance tree for the interface or directly
implement the interface in a concrete class, you don't break client code.

Point your colleagues to the many articles about "programming to the
interface", a best practice in O-O programming, and Java programming
in particular. They need to study more, and pay more attention to
your wisdom.

'Programming to an interface' does *not* refer to the syntactic
construct of an interface, but the semantic idea of a set of defined,
public methods. What in Smalltalk would be called a 'protocol'. An
abstract base class can define an interface for this purpose just as
well as an interface (IYSWIM).

It can.

And it does for all the languages that does not have a special
syntax for interfaces.

But an explicit interface syntax makes it a bit more stringent,
because it is enforced that it does not carry any implementation.

Arne

 

[Lew]

It does refer to the syntactic construct of an interface when it comes to best
practices in Java.

It can.

And it does for all the languages that does not have a special
syntax for interfaces.

But an explicit interface syntax makes it a bit more stringent,
because it is enforced that it does not carry any implementation.

The best practice in Java is to program to the interface according to Java's
definition of "interface". See Bloch, /Effective Java/, Item 18, "Prefer
interfaces to abstract classes".
Some of his points:

Existing classes can be easily retrofitted to implement a new interface.
Interfaces are ideal for defining mixins.
Interfaces allow the construction of nonhierarchical type frameworks.
Interfaces enable safe, powerful functionality enhancements

He goes on in that chapter to recommend implementating an interface with an
abstract class to provide default method implementations, and to publish the
interface to client code, just as the OP did.

 

[cbossens73]

It is a kind of philosophical question (since finally - it works bot
ways)... But - since I am quite new in JAVA [sic] (I comes from PERL and
shell programming) - it is interesting for me...
So - story is this:
I have family of classes - that share same interface (methods - that
they declare to "external world" as public) - "foo_interface"... They
also have large part of internal implementation - shared by all of
them ( attributes and protected methods)... So - I defined also
foo_interface and foo_abstract_class - that implements it... All
"real" classes - inherit from this foo_abstract_class... When I keep
references in arrays of objects , and serialize/desirealize them - I
keep them as instances of foo_interface... 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

All perfectly legitimate, idiomatic and beneficial.

colle[a]ges - that come from JAVA [sic] programming - says - it is
redundant
and interface is unnecessary... Is my implementation really something
fishy , or - it "does not break" rules og "JAVA [sic] world"???

Your colleagues are wrong. You should publish the interface name, not the
class name; that is the best practice. That way if you need to create an
additional inheritance tree for the interface or directly implement the
interface in a concrete class, you don't break client code.

Point your colleagues to the many articles about "programming to the
interface", a best practice in O-O programming, and Java programming in
particular. They need to study more, and pay more attention to your
wisdom.

'Programming to an interface' does *not* refer to the syntactic construct
of an interface, but the semantic idea of a set of defined, public
methods. What in Smalltalk would be called a 'protocol'. An abstract base
class can define an interface for this purpose just as well as an
interface (IYSWIM).

I strongly disagree with this.

In Java it is adviced for a lot of reason to "program to
a Java interface".

Abstract classes are a bad choice for a lot of reason. One
of them being that it can make testing *very* difficult.
I value testing above all else and it's been my personal
experience --and that of many others-- that abstract classes
simply cause too many problems, e.g. when trying to do mock
testing and when trying to reach 100% code coverage by test.
(others reason why they are a bad choice have been pointed
out to you by Lew, quoting Effective Java).

It is true that an OO interface can be defined in Java both
by using a Java interface of a Java "class" (either abstract
or not), but the latter is often poor design...

 

[Mark Space]

One
of them being that it can make testing *very* difficult.
This.


> It is true that an OO interface can be defined in Java both
by using a Java interface of a Java "class" (either abstract
or not), but the latter is often poor design...

Abstract base classes are good for providing a common implementation,
which is what the OP has done. But I agree that adding an interface
which also expresses the design is a no-brainer.

At minimum, what happens if you have only a abstract class, and want to
add your API to an existing class, or one that must extend another?

public class MyButton extends JButton implements Foo {

private Foo fooey = new AbstractFoo() { ... };

...

}

The combination of interface and abstract class allows composition,
where the abstract class by itself only allows inheritance.

 

[Tom Anderson]

Abstract base classes are good for providing a common implementation, which
is what the OP has done. But I agree that adding an interface which also
expresses the design is a no-brainer.

At minimum, what happens if you have only a abstract class, and want to add
your API to an existing class, or one that must extend another?

Then you refactor to separate an interface from the base class, which is
trivial to do, with or without a refactoring browser. Why on earth would
you do it before you need to?

The combination of interface and abstract class allows composition,
where the abstract class by itself only allows inheritance.

Great, so if you need to do that, use that combination. But until you do,
don't.

Writing code before you need it is a mistake. It's that simple.

tom

 

[Tom Anderson]

It does refer to the syntactic construct of an interface when it comes
to best practices in Java.

Many construe it to mean that, it's true.

The best practice in Java is to program to the interface according to Java's
definition of "interface". See Bloch, /Effective Java/, Item 18, "Prefer
interfaces to abstract classes".
Some of his points:

Absolutely. So when you need to do any of those things, separate the
interface and the base class.

What on earth does that mean?

He goes on in that chapter to recommend implementating an interface with
an abstract class to provide default method implementations, and to
publish the interface to client code, just as the OP did.

Another point on which i think Josh is talking sententious codswallop.
I'll add it to my list.

This reminds me of one of the problems that arises with design patterns.
When people first learn about them, it's very common for them to shoehorn
as many of them as they can into their code. But the thing about patterns
is that they aren't magical ingredients for making great code: they're
solutions to problems (or shapes of solutions to shapes of problems,
somewhat shadows-in-the-cave style), and if you don't have the problem,
applying the pattern doesn't solve anything, it just adds useless
verbiage. I think Josh Bloch (or perhaps his disciples) is making a
similar mistake. Yes, there are some practices which are always
appropriate, but there are some which are appropriate in certain
situations. This is the latter kind of practice, but the former kind of
situation.

tom

 

[Mark Space]

Then you refactor to separate an interface from the base class, which is
trivial to do, with or without a refactoring browser. Why on earth would
you do it before you need to?

Not really. If you have code that exists in several separate .jars,
which are widely disturbed over several systems, it can be a big pain to
get all of these individual .jars updated correctly.

Adding an interface (as in the Java keyword) to a design when you start
is pretty trivial, and doesn't in any way contribute to bloat or so
called "gold-plating."

If you're talking about concrete classes -- effectively final classes
which you directly instantiate -- then sure, not every single object in
a program needs to be part of some complex inheritance hierarchy. But
if you find yourself making a abstract class, at that point you might as
well add in interface to it. You'll be happy you did, some day.

 

[Tom Anderson]

I strongly disagree with this.

In Java it is adviced for a lot of reason to "program to
a Java interface".

Abstract classes are a bad choice for a lot of reason. One
of them being that it can make testing *very* difficult.

Aha, interesting.

I value testing above all else and it's been my personal
experience --and that of many others-- that abstract classes
simply cause too many problems, e.g. when trying to do mock
testing

If the base class is something that needs to be mocked for testing, and
the mock can't conveniently be constructed as a subclass, then that's a
perfectly good reason to refactor out an interface.

and when trying to reach 100% code coverage by test.

How so?

It is true that an OO interface can be defined in Java both by using a
Java interface of a Java "class" (either abstract or not), but the
latter is often poor design...

Often, perhaps - sometimes, certainly. But the point that seems to be lost
on many people here is that it isn't *always* poor design.

tom

 

[Mike Schilling]

Then you refactor to separate an interface from the base class,
which
is trivial to do, with or without a refactoring browser. Why on
earth
would you do it before you need to?

If you're writing a 10-class application where you write all the code
yourself, no reason at all. If you're creating a framework that
you're going to distribute widely, create the interface now because
changing all the APIs in version 2 is impolite.

 

[Arved Sandstrom]

Aha, interesting.

[ SNIP ]

I'd be interested to find out why an abstract class can make testing
*very* difficult. I can't think of any reasons.

AHS

 

[Lew]

What on earth does that mean?

It's explained in the referenced chapter.

 

[Tom Anderson]

If you're writing a 10-class application where you write all the code
yourself, no reason at all. If you're creating a framework that you're
going to distribute widely, create the interface now because changing
all the APIs in version 2 is impolite.

Another good reason to use an interface - if you're exposing the interface
to the world, where you can't refactor your users, then an interface gives
you some flexibility. But agaim, if you aren't, there's no need for it.

(Am i right in thinking that if i expose an abstract class Foo to the
world, i can't subseqeuently make Foo an interface and keep binary
compatibility? Since all those invokevirtual bytcodes would need to become
invokespecial, i assume not.)

tom

 

[Tom Anderson]

It's explained in the referenced chapter.

Okay. Since i don't have a copy of the book, i will thus assume it's
meaningless.

tom

 

[Mike Schilling]

(Am i right in thinking that if i expose an abstract class Foo to
the
world, i can't subseqeuently make Foo an interface and keep binary
compatibility? Since all those invokevirtual bytcodes would need to
become invokespecial, i assume not.)

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

 

[Lew]

Okay. Since i don't have a copy of the book, i will thus assume it's
meaningless.

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.