From: sally@projtech.com (Sally Shlaer)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: Project Technology, Inc., Berkeley, CA
Date: Tue, 8 Sep 1992 19:25:20 GMT



graham@maths.su.oz.au (Graham Matthews) writes:
>Get into a domain like mathematics where every object is related to
>every other object in many many ways, and OO begins to show its failures.

In <1992Sep6.003055.2236@tfs.com> eric@tfs.com (Eric Smith) writes:
>If you insist on modelling all possible relationships at once, then yes,
>it does get complicated.  But trying to model them without OO would be
>far more complicated.

Graham writes:
>There are many many
>more relationships that I cannot model with inheritance, so I am
>suggesting that people need to look very carefully at inheritance. 
                                                       ~~~~~~~~~~~

I would suggest instead that we need to look carefully at *additional
techniques* for modeling relationships.  In my experience, entities in 
the world are related in very interesting and complex ways -- and to
capture these relationships accurately requires a much richer topology
than can be attained with hierarchies alone.  For example:

     Dog Owner owns Dog

     Veterinarian provides medical services for Dog
     Dog Owner pays Veterinarian
     Veterinarian recommends Dog Food for Dog

     Pet Store stocks Dog Food
     Pet Store offers Dog Toy as a promotion for selling Dog Food

     Dog Owner buys Dog Food from Pet Store
     Dog prefers Dog Food

So here we have just 6 objects and at least 8 relationships -- none
of which have the generalization/specialization concept (i.e., inheritance).

Note that virtually all of the OO *analysis* methods allow you to model 
such relationship structures.

[Graham again:]
>There are many many
>more relationships that I cannot model with inheritance, so I am
                                  ~~~~~
>suggesting that people need to look very carefully at inheritance. 

But perhaps you meant "implement" rather than "model".  This suggests to me
that we should investigate the pros and cons of *different* techniques for
implementing relationships in various situations.  
Several ways spring to mind:

1.  Inheritance
2.  Use a pointer to point to the related object
3.  Use an instance variable to contain an identifier of the related object
4.  Define a class to implement the relationship, and use either a pointer
    or an instance variable with an identifier to link the related objects.
    (per the suggestion from eric@tfs.com (Eric Smith):
    >The trick is to see that relationships are themselves objects.  For 
    >example, the ways a line and a circle can relate to each other are 
    >the line-circle relationship, which is a subclass of the two-geometric
    >-figure relationship. 
5.  Eric's other suggestion:
    >For example, a specific relationship is a subclass of relationship,
    >because it "is a" relationship.  Q.E.D.  The same logic carries from
    >specific relationships to more specific relationships.  e.g., the
    >relationship between two animals is a base class of the relationship
    >between a bear and a bobcat, because the bear-bobcat relationship
    >"is a" two-animal relationship.  And the relationship between a bear
    >and a salmon is a subclass of the mammal-fish relationship, because
    >it "is a" mammal-fish relationship.  And the mammal-fish relationship
    >itself is a subclass of the two-animal relationship.  So you start to
    >see a tiny part of a vast inheritance structure of relationships.

Note that this last idea has a fundamentally different nature, in
that it constructs a class in a different domain (subject matter) --
the domain of OO (or relational theory, or whatever) and not the
domain of the application (Dog Care and Feeding).


Is it possible to state guidelines to help a designer decide what
is the best way to implement each of the relationships in
the Dog example above?  I would like to see a discussion
on this matter.

-- 
Sally Shlaer		sally@projtech.com
Project Technology	Training and Consulting using Shlaer-Mellor OOA/RD
Berkeley, CA		(510) 845 1484