Prev: SEO Optimization Software
Next: confused at associaton class in modeling library management system
From: Phlip on 9 Apr 2008 23:37
David Cressey wrote:

> 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?

What's the worst thing that could happen if you get this data model "wrong"
before you write the code?

--
Phlip


From: Michal Kleczek on 10 Apr 2008 07:13
Dmitry A. Kazakov wrote:

>[snip]
> 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.
>

I think it is not what OO is about (it does not mean it is not a good way of
programming).
IMHO object orientation is "a way of describing (and designing) systems as a
set of entities (objects) sending messages to (interacting with) each other
and reacting to received messages by changing their own state and/or
sending messages to other objects".
So there IS a difference between a message (the data contained in it) and a
receiver. The fact that you CAN define object oriented language using other
primitives such as functions operating on data structures does not matter
since OO is more about the way we THINK about systems and structure them
rather than the way we write it down using programming languages.

Michal
From: David Cressey on 10 Apr 2008 08:45

"Phlip" <phlip2005(a)gmail.com> wrote in message
news:47fd8b97$0$1120$4c368faf(a)roadrunner.com...
> David Cressey wrote:
>
> > 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?
>
> What's the worst thing that could happen if you get this data model
"wrong"
> before you write the code?
>

Philip,

It's a good question. I'm going to defer to people who have written a lot
of OO code. I hope they will answer.

I've seen what can go wrong, several times, where people have started with
the "wrong" data model and have built a database. There are various flavors
of "wrong" and various kinds of unfortunate consequences. If I had to
summarize, at the expense of over simplifying, I would say that the data in
the database will be less useful and more costly than it otherwise would
have been.

But it may be that the pitfalls in writing code and the pitfalls in building
a database are quite different. So I look forward to reading what
programmers have to say about this.


From: Phlip on 10 Apr 2008 10:28
David Cressey wrote:

>> What's the worst thing that could happen if you get this data model
>> "wrong" before you write the code?

> It's a good question. I'm going to defer to people who have written a lot
> of OO code. I hope they will answer.

Allow me: Nothing.

Firstly, the state variables in the messages sent between objects are, by
definition, dynamic and transient. The data in a database is static and
persistent. When OO objects share database records in their messages, the
records participate in this transient. As a program grows in versions, it's
natural for OO objects to change more often than database, but...

> I've seen what can go wrong, several times, where people have started with
> the "wrong" data model and have built a database. There are various flavors
> of "wrong" and various kinds of unfortunate consequences. If I had to
> summarize, at the expense of over simplifying, I would say that the data in
> the database will be less useful and more costly than it otherwise would
> have been.

These people did not make a (modest) investment in making sure they could change
their database over time. Look up "Rails ActiveRecord migrations" for a good
example how to do this.

> But it may be that the pitfalls in writing code and the pitfalls in building
> a database are quite different. So I look forward to reading what
> programmers have to say about this.

Write unit tests for everything you do, including the migrations, and pass them
after every few edits. These techniques make the cost of a bad database
negligible, if you can improve it over time, in response to new feature requests.

--
Phlip
From: Dmitry A. Kazakov on 10 Apr 2008 15:36
On Thu, 10 Apr 2008 13:13:42 +0200, Michal Kleczek wrote:

> Dmitry A. Kazakov wrote:
>
>>[snip]
>> 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.
>
> I think it is not what OO is about (it does not mean it is not a good way of
> programming).
> IMHO object orientation is "a way of describing (and designing) systems as a
> set of entities (objects) sending messages to (interacting with) each other
> and reacting to received messages by changing their own state and/or
> sending messages to other objects".
> So there IS a difference between a message (the data contained in it) and a
> receiver. The fact that you CAN define object oriented language using other
> primitives such as functions operating on data structures does not matter
> since OO is more about the way we THINK about systems and structure them
> rather than the way we write it down using programming languages.

I think OO has long overgrown this limiting point of view.

So, you should agree with David Cressey, because your approach is
sufficiently incomplete. For you cannot handle either the content of
messages or the object states within your framework. From this immediately
follows that your approach is secondary to one capable to describe that, in
David's opinion to data. That was his, DB POV.

P.S. Why can't I send one object to another? Isn't it an old misconception
about nature of identity? Consider an electronic signature as a
counterexample of a marshaled object.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: SEO Optimization Software
Next: confused at associaton class in modeling library management system