Re: Question on abstract classes versus interfaces

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. And,
indeed, it is signified by a different keyword in Java -- so a hearty "Well
done!" to Mr Gosling ;-)


- 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. This is where the notion of interface ==
contract may help. Consider this:

feed(Object animal) // <-- note: "Object"
{
animal.eat();
}

In many languages this would work perfectly well, provided that the objects
passed to feed() did /in fact/ have methods called eat(). So we would have
polymorphic behaviour among all objects which have an eat() method. But what if
one /didn't/ have such a method ? Languages have many ways of dealing with
this; the Java way is for the compiler to try to prove, in advance, that it
can't happen. One way to do that is to set up a promise by the object that it
will have a method called eat():

class Cow
implements FarmInhabitant
{
void eat{) { .... }
}

and a requirement by the user of the object that it must have the method:

feed(FarmInhabitant animal)
{
animal.eat();
}

Now we have a requirement and a promise to satsify it. The compiler checks
that the contract is satisfied, which it is, and so allows the code. There's
no inheritance involved at all.

(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.)

It would be perfectly possible to define a completely OO language which didn't
have inheritance (concrete or otherwise) at all. Such a language would have
either a dynamic type system, or a fiendishly complicated static one, but it
could be built, and it would work, and one could do clean OO programming in it.

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. My hypothetical language would be terrible at both
(unless it used some innovative scheme for code-sharing without
inheritance[*]).

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. So, although one
can achieve that level of cleanliness, it's probably better to save it for
"important" places, such as package boundaries, or boundaries between
independent APIs.

-- chris


([*] Delegation-based OO languages, such as Self and ECMAScript, fit this
description.)


.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... >>>dynamically checked OO languages, but iirc that isn't the case. ... >> I have written enough code in Smalltalk, ... to know that polymorphism and inheritance are not ...
    (comp.object)
  • Re: Advantages of object-oriented programming
    ... consider classes or inheritance to be a neccessary part of the ... Class systems are absolutely crucial to OOA/D because they provide the level of abstraction for logical indivisibility, provide a basis for problem space abstraction, and enable relationships whose participation is the primary mechanism for limiting access to state variables in the OO paradigm. ... Since inclusion polymorphism is one of the more important OO tools and it is enabled by generalization, ... In this respect the OOPLs use exactly the same conventions as procedural languages; they just support a broader range of types. ...
    (comp.object)
  • Inheritance and Polymorhpism (getting back to the point)
    ... >replaced with an inheritance hierarchy. ... languages that, for the purpose of this discussion, we shall call ... "common statically typed languages") polymorphism is achieved through ... is also stipulates that there may be some dynamically typed languages ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... >>> I have written enough code in Smalltalk, ... to know that polymorphism and inheritance are not ... >>> associated in those languages. ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... >>> I have written enough code in Smalltalk, ... >>> associated in those languages. ... "polymorphism and inheritance are not associated in those languages" ...
    (comp.object)