Re: Question on abstract classes versus interfaces

Re Chris,

Chris Uppal wrote:
alexandre_paterson@xxxxxxxx wrote:

- if "MI of interfaces" isn't like MI at all, like you're saying,
do you conside single inheritance of interface inheritance at all?

I hadn't thought of it before but now you mention it,

:)


no, I don't. There is
(single) inheritance between Java classes, signified by the keyword 'extends'.
And there is (multiple) inheritance between Java interfaces, also signified by
the keyword 'extends'. But I don't think the relationship between a class and
the interfaces it implements should be called inheritance at all.

OK, I agree that the relation between a class and the interfaces it
implements isn't "inheritance", but this wasn't exactly what I had
in mind...

When we've got this:

interface A {
... doStuffOne();
... doStuffTwo();
}

interface B extends A {
... doStuffThree();
}

can't we say that interface B is inheriting the contract defined by
interface A ?



And, indeed, it is signified by a different keyword in Java -- so a
hearty "Well done!" to Mr Gosling ;-)

I agree that some keywords are confusing... "final" comes to mind too.

:)


- do you think it is mandatory to rely on concrete inheritance
to achieve OOP ?

Well, it certainly isn't /mandatory/. OO is about objects with polymorphic
behaviour; inheritance (although ubiquitous) is not at all central to OO --
it's hardly even relevant to OO.

That's exactly what I think: it's hardly relevant to OO.

But /many/ people do think OO == (implementation) inheritance. :(


(There are other ways to express this using words like "type", instead of
"contract", and they are perfectly correct too. But I believe that they tend
to divert attention away from the pure OO concept of polymorphic behaviour. In
particular they tend to produce a confusion between inheritance and
polymorphism.)

I tend to like and use the term ADT ("abstract data type").


It would be kind of hard to work with, though. Inheritance is used for two
very important things in real life languages: labour saving and expressing
/necessary/ similarities.

But for expressing necessary similarities in Java you can use
interfaces:
- two objects implementing the same interface are promising to satisfy
a same contract
- an object implementing an interface promise to satisfy the contract
defined by an interface and hence all the contracts defined by the
"parent interfaces" hierarchy.

I don't see right now how OO could exists without at least that kind
of "specification inheritance" / "contract inheritance" (in Java
"interface A extends B").

Now I'm not sure that's what you meant by "similarities", if you're
talking about code re-use, then (concrete) inheritance may be more
convenient than delegation.


Bjarne Stroustrup said:

"A language or technique is object-oriented if and
"only if it directly supports:
"
"(1) Abstraction - providing some form of classes
" and objects.
"(2) Inheritance -- providing the ability to build new
" abstractions out of existing ones.
"(3) Run-time polymorphism...

Link here: http://www.research.att.com/~bs/oopsla.pdf


This can be done in Java in different ways... What I do is:

1. define my abstract data types using interfaces
2. build new abstract data type based on my
existing interfaces (wether "simple" or "multiple" "extends").
(I'd tend to say this is pretty close to, say, Stroustrup's
definition of "inheritance").
3. sure enough I can see polymorphism at work in
my Java programs (without ever relying on implementation
inheritance).

Now I don't claim to know the one true definition of OO... I just
try to code in an OO'ish way in Java.


Switching to the more relevant question of whether one can do OO without
concrete inheritance /in Java/, I would say that roughly the same answer comes
out. It is certainly /possible/ to do clean OO using only interfaces to manage
polymorphism, but in practice it's a right pain in the arse.

I've seen that said very often but I don't find it too hard to do.
I do (obviously seen that I'm always using interface) rely on
delegation quite a lot. But I don't think it's a problem: my IDE
allows me to delegates all methods to an object in a single shortcut.

Put it in another way: I think the benefits of not using implementation
inheritance (easier testing, easier refactoring, cleaner representation
of my abstract data types, easier documentation [the documentation
lies on the interface, not mixed with code]) outweight the
disadvantages (less convenient to re-use code and hence lots of
delegation everywhere).

As always it's just an opinion and YMMV :)

Talk to you soon on c.l.j.p. and thanks for always taking the time to
discuss these kind of things!

Alex

.

Relevant Pages

  • Re: CLOS Properties Question
    ... This leads to what they call shadowing (at least in Java) ... In interfaces, you can declare methods, but you ... > field declaration in an interface could just have led to the requirement ... > Back to the question what this all has to do with multiple inheritance: ...
    (comp.lang.lisp)
  • Re: Tired of 100s of stupid Getter/Setter methods
    ... but interface does not hide the other methods of implementing ... telling you that you need to refactor a new common superclass. ... Again, composition instead of inheritance. ... A StringVector cannot take Integer parameters. ...
    (comp.lang.java.programmer)
  • Re: Beginner, Which language
    ... > That's much more true for implementation inheritance than interface ... > compared to the run time support Java requires. ... > - All base classes of the interface must also be declared with interface ...
    (comp.programming)
  • Re: Template method pattern in Java ???
    ... > only caveats being that contracts may refer to other routines and it ... Perhaps we need two kinds of interface: ... > also allows for the inheritance of non-purely abstract classes. ... This is different in Java ...
    (comp.object)
  • Re: Template method pattern in Java ???
    ... > only caveats being that contracts may refer to other routines and it ... Perhaps we need two kinds of interface: ... > also allows for the inheritance of non-purely abstract classes. ... This is different in Java ...
    (comp.lang.java.programmer)