OOP
in [OOP]
|
Prev: OO Question
Next: Why is Object Oriented so successfull
From: David Cressey on 9 Apr 2008 00:04 How does one model behavior? It would seem to me that, since conveying behavior from one object to another rests on messages, and since messages are made of data, that one needs a data model for the messaging system before one begins to come up with a bhavior model for a system of collaborating objects. Or is there another completely different way of setting things up?
From: Dmitry A. Kazakov on 9 Apr 2008 03:07 On Wed, 09 Apr 2008 05:04:10 GMT, David Cressey wrote: > How does one model behavior? Behavior of what? Of the program, of a physical system? > It would seem to me that, since conveying behavior from one object to > another rests on messages, and since messages are made of data, that one > needs a data model for the messaging system before one begins to come up > with a bhavior model for a system of collaborating objects. > Or is there another completely different way of setting things up? Yes, messages are just certain kinds of operations built upon something else. Thus in my view OO is not about messaging and messaging is not all behavior. To your point about messages parameters. Yes, you could try to treat them as data. But that would not solve the problem of defining the behavior of these "data." Further there is no difference between the message parameters and the message's recipient. They all are values of some types. So the message X sent to T with a parameter V is simply an operation X defined on both types T and V. Neither is better than another, they are equal. Mutability is not an issue here. When the recipient of the type T is mutable, then X is defined as X : T x V -> T Any mutable operation can always be described in an immutable way. You just bind one in- and one out-parameter to the same object. Certainly the behavior of some types is derived from / defined by the behaviors of others. Surely there could be predefined types of which values behavior is postulated. Moreover, it has to be done, not only for mathematical reasons. The advantage of not inferring behavior is huge. You can have all sorts of hardware, remote/software components behaving as a "random number," as a "clock," as a "real number," as, for that matter, an RDBMS, without deducing that. This is why OO shines in large, complex, mission-critical software design. In short it is called separation of implementation and interface. Returning to your point, you need a type system prior both messaging and data. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: David Cressey on 9 Apr 2008 07:59 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:zkim348wbex9.1o1jsucpvgtg8$.dlg(a)40tude.net... > On Wed, 09 Apr 2008 05:04:10 GMT, David Cressey wrote: > > > How does one model behavior? > > Behavior of what? Of the program, of a physical system? > > > It would seem to me that, since conveying behavior from one object to > > another rests on messages, and since messages are made of data, that one > > needs a data model for the messaging system before one begins to come up > > with a bhavior model for a system of collaborating objects. > > > Or is there another completely different way of setting things up? > > Yes, messages are just certain kinds of operations built upon something > else. Thus in my view OO is not about messaging and messaging is not all > behavior. Alan Kay has suggested that he placed too much emphasis on objects, and not enough on messages. http://en.wikipedia.org/wiki/Message_passing > > To your point about messages parameters. I didn't mention parameters. I don't know what you mean.
From: Leslie Sanford on 9 Apr 2008 09:23 "David Cressey" wrote: > "Dmitry A. Kazakov" wrote: >> David Cressey wrote: >> >> > How does one model behavior? >> >> Behavior of what? Of the program, of a physical system? >> >> > It would seem to me that, since conveying behavior from one object to >> > another rests on messages, and since messages are made of data, that >> > one needs a data model for the messaging system before one begins to >> > come up with a bhavior model for a system of collaborating objects. <snip> >> To your point about messages parameters. > > I didn't mention parameters. I don't know what you mean. As I understand it, sending an object a message at the code level means invoking one of its methods. A method takes zero to many parameters, or arguments. When you say that messages are made up of data, my point of view translates that to meaning the arguments passed to methods, i.e. the arguments are the data. Perhaps that's the impression Dimitry got as well. Further, when you say "that one needs a data model for the messaging system before one begins to come up with a behavior model for a system of collaborating objects," I translate that to mean that one should "model" the data passed between objects via their methods first before modeling how the objects respond/behave to messages (method invocations). Which is fine, I guess, but usually when designing a class I decide what it needs to do, and this goes hand in hand with what it needs to know in order to do it. To me it's like working with algorithms (or behavior) and data structures (or data). I can't say if one comes before the other. Could be my head is stuck at the code level which is where I mainly live and I don't understand what it is you're asking. In which case, I welcome enlightenment/clarification.
From: David Cressey on 9 Apr 2008 10:00
"Leslie Sanford" <jabberdabber(a)bitemehotmail.com> wrote in message news:47fcd175$0$11371$4c368faf(a)roadrunner.com... > > "David Cressey" wrote: > > "Dmitry A. Kazakov" wrote: > >> David Cressey wrote: > >> > >> > How does one model behavior? > >> > >> Behavior of what? Of the program, of a physical system? > >> > >> > It would seem to me that, since conveying behavior from one object to > >> > another rests on messages, and since messages are made of data, that > >> > one needs a data model for the messaging system before one begins to > >> > come up with a bhavior model for a system of collaborating objects. > > <snip> > > >> To your point about messages parameters. > > > > I didn't mention parameters. I don't know what you mean. > > As I understand it, sending an object a message at the code level means > invoking one of its methods. A method takes zero to many parameters, or > arguments. When you say that messages are made up of data, my point of view > translates that to meaning the arguments passed to methods, i.e. the > arguments are the data. Perhaps that's the impression Dimitry got as well. > I'm not really asking at the code level. I think a message specifies an operator, not a method. The relation between operator, class, and method has to be managed somewhere. At the code level, you are probably right. > Further, when you say "that one needs a data model for the messaging system > before one begins to come up with a behavior model for a system of > collaborating objects," I translate that to mean that one should "model" the > data passed between objects via their methods first before modeling how the > objects respond/behave to messages (method invocations). Which is fine, I > guess, but usually when designing a class I decide what it needs to do, and > this goes hand in hand with what it needs to know in order to do it. To me > it's like working with algorithms (or behavior) and data structures (or > data). I can't say if one comes before the other. > > Could be my head is stuck at the code level which is where I mainly live and > I don't understand what it is you're asking. In which case, I welcome > enlightenment/clarification. > Sorry. I don't know enough OO to provide enlightenment. I understand data pretty well. Perhaps you could tell me how you express "what a class has to do". This might be close to what I'm asking for when I say "how to you model behavior". |