Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.object Subject: Re: Objects and Interactions: Separate Definitions Message-ID: Date: 21 May 91 20:54:34 GMT Article-I.D.: uunet.CIMSHOP!DAVIDM.91May21135434 References: <3999@motcsd.csd.mot.com> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California Lines: 96 In-reply-to: lance@motcsd.csd.mot.com's message of 21 May 91 01:52:20 GMT >>>>> On 21 May 91 01:52:20 GMT, lance@motcsd.csd.mot.com (lance.norskog) said: Lance> preece@urbana.mcd.mot.com (Scott E. Preece) writes: Scott> In article <1991May3.212005.29453@visix.com> amanda@visix.com (Amanda Scott> Walker) writes: Amanda> ... A trivial example of this idea is that a heapsort Amanda> should operate on any set of objects for which I can provide Amanda> comparison and exchange operations. In object orientation, this seems to never be quite right. The real way of expressing a HeapSort() operation is that it operates on any set of Sortable objects (which is defined as having a comparison operation). Often, though, this looks like overkill as it expects an awful lot of things to derive from Sortable. Scott> OK, let me expose my ignorance[1]. I'd like to see how object-oriented Scott> design works. Would you care to sketch the design for this? My naive Scott> model would be that a heap is an object and that it has add and remove Scott> methods to take objects of unspecified type and stick them into the Scott> heap in the right place. So where do the comparison and exchange Scott> procedures go? I see two alternatives[2]: (1) the heap object has Scott> compare and exchange methods that "know about" all of the types, figure Scott> out what's involved, and operate on the member objects or (2) the Scott> objects have methods that report their "comparable value" and size in Scott> canonical forms that a generic routine in the heap object can operate Scott> on. Neither of these makes me awfully happy. Actually, using Sortable as the base class for anything that HeapSort() can work on eliminates a lot of conceptual problems, but the methodology for implementation still has a number of technical problems. One method is a technique called (I think) double polymorphism which is a tricky way of having the derivatives of Sortable promote themselves up the hierarchy until comparible values are found. Lance> Standard practice, like Smalltalk, follows (2). C++ seems to do (1) Lance> for handling type conversions. I think it could be done equally well in both languages, it just depends on the frame of mind of the implementor. An article on Generic Mathmetics (I think) appeared in Journal of Object-Oriented Programming in January and explained the ideas of double indirection better than I could. Lance> Class definitions seem to have two jobs: a) defining the "Buddha Lance> Nature" of a class, and b) defining the interactions of that class and Lance> some other class. B) generally involves describing a particular Lance> interaction in two different places: one in the class, and another in Lance> some other class that interacts with the first class. I'm happy Lance> putting A) in a class definition, but B) splits the interaction into 2 Lance> different places, increasing "code entropy". Lance> An alternative is to have a separate set of declarations which define Lance> interactions between objects. These interaction definitions are where Lance> you code up classic algorithms. True, but this "interaction definition" can be thought of as an object in its own right and, therefore, coded as a class. Lance> Let's say we have objects X and Y, and that in Smalltalk X would use Lance> Y in some way, by sending it messages and interpreting the responses. Lance> With interaction definitions, X would say "Start interaction Z Lance> with Y". An instance of interaction definition Z is created, Lance> and it sends any number of messages to X and Y, interpreting the Lance> responses. Objects don't send messages to other objects. Well, Entities don't communicate directly with other entities, they communicate via Relationships (you mentioned E-R later). Either the relationship controls the interaction by being the initiator of any interaction between entities or by being the go-between for the entities. Lance> Separating objects and their interactions shears class definitions Lance> of descriptions of their dealings with other specific objects, and Lance> leaves them only with a small, simple set of messages and responses. Lance> My theory is that this will encourage defining small, simple, Lance> reusable objects. Possibly, but it shouldn't be carried too far. Consider that inheritance could also be looked at as the interaction of two objects. Also, how do you handle a List class (which interacts with everything in the list)? Lance> I've heard the term entity-relationship (ER) bandied about, and seen Lance> it in books, but haven't tracked down a full comprehension. Lance> It may be that I'm crossing ER with objects. Which is not necessarily a bad cross. ER is used for determining Entities and Relationships which is very useful for understanding object definitions as well. Relationships can be treated, though, as objects just as easily as Entities. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"