Re: Real OO

[stt@henning.camb.inmet.com (Tucker Taft)]

Don Harrison (donh@syd.csa.com.au) wrote:
: Tucker Taft writes:

: :Eiffel tries to support this effort through class invariants, but
: :I believe it gets tripped up a bit by the conflict between establishing
: :useful invariants for a specific type/class in the class
: :hierarchy, which might want to be quite "tight" so as to catch as
: :many errors as possible, and the appropriate invariants for the 
: :entire class hierarchy, which want to be as "loose" as possible 
: :to ensure flexibility of extension.  There seems to be
: :a need to have two separate kinds of invariants -- those that apply to
: :an individual type/class, and a separate set that get "inherited",
: :and that apply throughout the class hierarchy.

: Because Eiffel invariants are ANDed with ancestor invariants, they become 
: successively tighter in descendants. Doesn't this fit the bill?

No.  

The problem is that when you write an assertion, you must
decide whether you are trying to constrain the current type/class
as tightly as possible, to catch as many bugs in it as possible, or
to constrain it as loosely as possible, to allow as much flexibility
as possible in descendant type/classes.  

Clearly, if the type is deferred/abstract, then the assertions 
are only of interest in descendant types/classes, and so clearly 
should be as loose as possible to maximize flexibility of 
implementation.  However, when you have a non-deferred/non-abstract 
("concrete") class which nevertheless might have descendants, you end 
up in the quandary.

It would be reasonable to have both kinds of assertions.

Right now, I suspect a common scenario is that when someone first
writes a "concrete" type/class, they write the assertions
relatively tightly.  Then, if they later start creating
descendants of it, they might discover an assertion that
is unnecessarily over constraining, and go back and loosen
it on the parent type/class.   This loosening may eventually
result in overly weak assertions on the parent type/class, so 
that future maintenance on the parent type/class itself might be 
more likely to violate what must now be "unwritten" 
assumptions/assertions.

An alternative scenario might be to convert a concrete class
into an abstract/deferred one when it starts to run into
this problem, with the original concrete functionality being
moved down into a descendant, where the tighter assertions
may be retained.

Another way to look at the problem is whether the assertions
are focused on the "client" view or the "server" view.
For a deferred/abstract class, there is no real server,
so the assertions are clearly client oriented.  However
for a concrete class, the client view and the server view
are different, and it makes sense to keep the client-oriented
assertions as weak as possible (but no weaker!), while making
a specific server's "local" assertions as strong as possible so
as to catch as many bugs as possible.

The simplest solution might be to distinguish whether a given
assertion should apply only on a specific type/class, or should
apply on all descendant types/classes as well.  Clients should of 
course only be interested in those assertions that apply to all
descendant classes as well, whenever they want to operate without
knowledge of and/or dependence on the specific type/class
providing the implementation.

: Don.               (o o)
: =-=-=-=-=-=-=-=oOO=-(_)-=OOo=-=-=-=-=-=-=-=-
: Don Harrison             donh@syd.csa.com.au

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA