Re: vocabulary
On 5/4/2014 8:00 AM, Chris Uppal wrote:
Martin Gregorie wrote:
It seems to me that the only reason Java has both Abstract Class and
Interface definitions is to sidestep having to implement multiple
inheritance
FWIW, I disagree with this entirely.
For me, as for [some] others, interfaces are an expression of a /contract/ --
they are used to communicate guarantees/requirements between producers and
consumers of APIs.
Abstract classes, on the other hand, are nothing to do with contractual
communication between programmers. They are skeleton implementations.
[...]
In what way does an abstract method declaration in an abstract class
differ from an abstract method declaration in an interface? ISTM that
all abstract methods, wherever embedded, impose identical "contractual"
requirements on their concrete implementations.
As for "skeleton implementations" ...
abstract class Abstract {
abstract void setThing(Object obj);
abstract Object getThing();
}
interface Abstruse {
void setThing(Object obj);
Object getThing();
}
There *is* a tiny skeletal shard to the former that the latter lacks:
Abstract has a constructor, while Abstruse does not. But Abstract's
constructor is pretty minimal: A mere bone splinter, not a structural
element that can support weight and anchor muscles. I think that if
you tried to argue that Abstract's trivial constructor amounted to an
"implementation," you'd get at best a grudging "Well, *technically*"
in response.
By the way, one of the more intriguing (to me) uses of an abstract
class is to "un-implement" something:
abstract class Disinheritor {
abstract String toString();
}
A subclass of Disinheritor must provide its own toString() method, and
cannot simply inherit Object's. So, does that make Disinheritor an
"anti-skeleton implementation" or a "skeleton anti-implementation?" ;-)
--
Eric Sosman
esosman@comcast-dot-net.invalid