Re: Question on abstract classes versus interfaces

alexandre_paterson@xxxxxxxx wrote:

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

Yes, indeed we can. Or that's what /I/ think (and it seems that everyone else
agrees with me so they must be right ;-)


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

I agree.

However, we can console ourselves with the reflection that they are wrong, and
so can be ignored (wherever practical).


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

I'm not too fond of it myself. I can see the reasoning, but that way of
looking at object puts (IMO) too much emphasis on the /code/ (i.e. the class
represented as source code); rather that on the /objectS/ themselves. E.g. it
does not flaunt the idea that each instance of the ADT has a separate identity
and history. Another example: if you talk of ADTs it's hard to know whether
you are talking about the class or its instances -- the term (IMO) tends to
conflate the two. A last example: I think it's valuable to anthropomorphise
the objects in a program (consider them as if each were a person) as, for
instance, in responsibility-based design. I don't know about you, but I would
find it a lot harder to anthropomorphise an "abstract data type" -- somehow it
doesn't sound much like a person ;-)


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

I agree. It would probably be impossible. At best it would be insanely
difficult to work with.


Now I'm not sure that's what you meant by "similarities",

I was meaning the case where two classes (or two interfaces, come to that)
/must/ share certain features. One way of expressing that relationship (and a
good way to ensure that the relationship is maintained) is for one class to
inherit that feature from another. (Or for both to inherit it from a third).
In a language with no form of inheritance or delegation, that relationship
would have to be maintained through "cut-and-paste inheritance" (or rather
"cut-and-copy"), which is neither expressive nor easy to maintain.


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

I think he's wrong about (2).


[description of working practice snipped]
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.

Sounds a reasonable way of working to me -- if it suits you. I think it would
be more work than I care for (except, as I said, at sub-system boundaries), but
see below...


my IDE
allows me to delegates all methods to an object in a single shortcut.

Just an observation: that's getting quite close to defining your own language
layered over Java -- one with a different approach to OO in general. It only
requires one more step -- you do this so often that you instruct your IDE to
generate, or re-generate, these delegation methods automatically (so it does it
every time without having to be told) -- and you will effectively be using
different language. One that is upwardly compatible with, but not the same as,
Java.


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

It's always interesting to discuss how we think about programming.

Cheers.

-- chris


.

Relevant Pages

  • Re: Darkroom software Help
    ... Apple's computer operating system OS-X includes the Java ... programing language, compiler, and integration software. ... have an Apple this fall. ... Said that, my system is based on a commercial lab interface, the ...
    (rec.photo.darkroom)
  • 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: [OT] Java, C#: why no multiple inheritance?
    ... > inheritance doesn't mean that it will definitely involve the dreaded ... Then, derive a Frogosaur class from Frog, Dinosaur. ... > usage of other language possibilities can also produce ugly situations. ... That's fine in Java. ...
    (comp.lang.cpp)
  • Re: Multiple Inheritance
    ... Java has multiple inheritance. ... This is due to the original ideas from a language called Smalltalk and then being propagated along by marketers and/or Java language designers ...
    (comp.lang.java.programmer)
  • Re: Question on abstract classes versus interfaces
    ... do you conside single inheritance of interface inheritance at all? ... And there is inheritance between Java interfaces, ... of my abstract data types, ...
    (comp.lang.java.programmer)