Re: Interface/Implementation (was Re: Design by Contract)

[mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]

Nick <nickle@calfp.co.uk> wrote via Owen Fellows <ofellows@calfp.co.uk>
about supposedly "pure" OO a la Eiffel vs. Ada-like modules and types as
different concepts and non-method procedures:
> But it it more likely that you just inherit MATHEMATICIAN somewhere in
> your heirarchy to save on typing.

I find that totally unacceptable, as it creates much too strong coupling
between library modules and their clients. Adding new features to a library
module shouldn't force even the smallest change in any previously existing
clients. The same applies to unavoidable visibility of every parent feature
in children - to avoid potential clashes, one is forced to revert to using
long_feature_names_saying_they_are_only_for_class_X_and_not_for_children,
which is a shame for a somewhat recent language like Eiffel (even in old
K&R C you had private - aka static - functions/variables), in my view. The
point isn't so much about children touching conceptually private features
of parents where they shouldn't do that (though that does get "interesting"
in large projects with say, 50 to 100 programmers of varying quality, and
I'd rather have that checked, too), but about clean separation of concerns
and minimal coupling.

> Having the same implementation as inherits is a hint that it probably is
> inherits!

No more than the implementation of loops via conditional goto is a hint to
drop explicit loops from the language and only provide conditional goto (and
perhaps call/return) as control structure. I expect most people wouldn't
follow the latter reasoning (nor do I), and likewise I disagree with your
above suggestion. In fact, I'd already use inheritance much less than what
seems to be usual in the Eiffel world (if Bertrand Meyer's books are a hint
about general usage): Even if it means more writing, I prefer having a mere
client for an object via a field over implementation inheritance: As long as
the representation type can be used unchanged via its abstract interface,
I'll do so. If it's mostly right, but still no proper "is-a" relation holds,
I'll also seriously consider a different subclass with some small changes
for the different need, and then using this adaption as client in that new
type which really isn't a proper subtype. I find this to be much better at
decoupling, more explicit about the essential relations between those types,
and more readable for my taste. The counter-argument about inefficiency due
to another indirection doesn't hold, as the above is only about source level
stuff: If performance is critical, make the compiler sufficiently clever to
inline the respective data and operations for such cases, which should be
quite trivial. The counter-argument about needing all the facilities which
are used for inheritance again for import doesn't really work either, since
the usage of library modules with qualified names for feature access doesn't
need things like renaming, redefinition, re-export or hiding; simply write
e.g. Math.Sin(X) and stop worrying about name space pollution. (Well, you
do have to think about module names, which should ideally be a hierarchical
name space, similar to Ada child packages or Java packages, but it reduces
the amount of relevant names dramatically.)

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>