Prev: object level locking and class level locking
Next: Business objects, subset of collection
From: lars_oberg on 12 Jan 2008 14:06
Hi,

I am trying to improve my OOD abilities and I reading "Object
Thinking" by David West. I came across a couple of things in this
book that I do not understand and I hoping someone here can help me
clarify this.

On p. 128, he defines the term Message:

"Messages frequently take the following form:
Receiver Selector (Arguments) <- returnedObject or Receiver.Selector
(Arguments):ReturnedObject

<snip>

returnedObject is an arbitrarily complex object containing or
representing the result created as a consequence of receiving the
message. In the case of imperative and declarative messages, the
object returned is "self," that is, the object that received the
message is indicating it's still available to you (usually by keeping
an active pointer). In Java, and most popular languages, imperative
and declarative messages are void functions. No return is expected.
If the object changed in any way as a result of receiving the message,
the 'self' that is returned is the newly constituted 'self.' "

I have two questions on the above:
1) "In the case of imperative and declarative messages, the object
returned is 'self' ...indicating it's still available to you (usually
by keeping an active pointer)" I don't get this - in order to have
sent a message to the object, you must already have had a reference to
it, so why would you need it to return a pointer to self? Also,
imperative and declarative messages usually do not return anything
(void). Unless he is talking about a static factory or something...

2) The last sentence, " If the object changed in any way as a result
of receiving the message, the 'self' that is returned is the newly
constituted 'self.' " I do not understand this sentence and I do not
understand how void functions are returning anything.

If anyone could please clarify the above, I would be very grateful.
The definition of a Message is so fundamental to OOP that I really
want to fully understand it.

Thanks,
Lars

Ps. I am from a C/C# background, and the author seems to using some
SmallTalk & Object C terms, so maybe this is part of why I do not get
it.



From: Daniel T. on 12 Jan 2008 18:21
lars_oberg(a)hotmail.com wrote:

> I am trying to improve my OOD abilities and I reading "Object
> Thinking" by David West. I came across a couple of things in this
> book that I do not understand and I hoping someone here can help me
> clarify this.
>
> On p. 128, he defines the term Message:
>
> "Messages frequently take the following form:
> Receiver Selector (Arguments) <- returnedObject or Receiver.Selector
> (Arguments):ReturnedObject
>
> <snip>
>
> returnedObject is an arbitrarily complex object containing or
> representing the result created as a consequence of receiving the
> message. In the case of imperative and declarative messages, the
> object returned is "self," that is, the object that received the
> message is indicating it's still available to you (usually by keeping
> an active pointer). In Java, and most popular languages, imperative
> and declarative messages are void functions. No return is expected.
> If the object changed in any way as a result of receiving the message,
> the 'self' that is returned is the newly constituted 'self.' "
>
> I have two questions on the above:
> 1) "In the case of imperative and declarative messages, the object
> returned is 'self' ...indicating it's still available to you (usually
> by keeping an active pointer)" I don't get this - in order to have
> sent a message to the object, you must already have had a reference to
> it, so why would you need it to return a pointer to self? Also,
> imperative and declarative messages usually do not return anything
> (void). Unless he is talking about a static factory or something...

He is wrong as to why the self object is being returned. Returning self
allows message chaining. So for example (Java):

class Foo {
public Foo message1(); // returns this
public Foo message2(); // returns this
}

myFoo.message1().message2();

> 2) The last sentence, " If the object changed in any way as a result
> of receiving the message, the 'self' that is returned is the newly
> constituted 'self.' " I do not understand this sentence and I do not
> understand how void functions are returning anything.

In Java (and most popular languages,) "this" is an in/out parameter to
the method. Thus there is a return although it is not explicitly
declared.

> If anyone could please clarify the above, I would be very grateful.
> The definition of a Message is so fundamental to OOP that I really
> want to fully understand it.
>
> Ps. I am from a C/C# background, and the author seems to using some
> SmallTalk & Object C terms, so maybe this is part of why I do not get
> it.

Yes, just based on that one paragraph, I'd say the book is very
SmallTalk centric. C++ uses different terminology... A "message" is a
call to a virtual function. A "method" is a virtual member-function. A
"field" is a member-variable. "Child" or "Sub Class" is a derived class.
"Parent" or "Super Class" is a base class.
From: lars_oberg on 13 Jan 2008 00:25
>   I would not try to attempt to »learn OOP«, but to learn
>   »Smalltalk« or »Java« or any other specific language. (But
>   not all languages at the same time.)
Actually, I have been programming in OOP languages for many years, but
feel I am not getting the level of code-reuse I would like to get so I
am trying to read up on OOD to improve this. The author of the book,
David West, is quite well known in this area but he addresses the
topic in a very different way - a good chunk of the book delves into
philosophy and culture underlying "object thinking" (he goes all the
way back to Plato). He contends that the vast majority of people
purporting to do OOP are really only writing procedural code inside of
classes (because they never really understood the philosophy and ideas
underlying OOP). The book was highly recommend by Rockford Lhotka,
who I respect a lot, but so far the book has proven to be a piece of
work due to the high-flown language and somewhat vague concepts.

>   To learn object-oriented programming as conceived by the one
>   who coined the term »object-oriented programming«, learn
>   Smalltalk or Squeak.
Yes, I have actually been considering learning Small Talk to better
understand the ideas of the people who created OOP (like Kristen
Nygaard and Alan Kay), but since this is a dead or dying language (at
least for new projects in the non-academic world) I don't know if it
will be worth the effort.

>   If you want to learn what the inventor of the term
>   »object-oriented« intended to refer to by »message«, you should
>   look in Smalltalk or Squeak.
>
>   For example:
>
>       »Once an object is running inside a Smalltalk environment,
>       its data can only be accessed by its methods, and its
>       methods can only be worked by sending the object a
>       message. (See: encapsulation.) A message is a string which
>       names the object followed by a name for one of its
>       methods, followed possibly by parameters.«
I just had a small realization reading that quote - it says that "a
message is a string which names the object..." In a late-binding
language / environment, you probably often don't have compile-time
checking to make sure the messages you send to objects are defined on
these objects, so the message would be a simple string that the object
would then check against its defined methods to ensure it is a valid
message. Do I have that straight?


I have one more section from the book that maybe you (or someone) can
help with as well:
" 'Collaboration' and 'collaborator' are terms referring to a
particular type of object cooperation and the object relied upon for
that cooperation. <snip> Collaboration occurs when
1) Object A receives a request for one of its advertised services.
2) While in the process of satisfying that request, it needs to ask
for a service from object B
3) Object B is _not_ an object occypying one of object A's instance
variables, a temporary variable declared in the method that object A
is executing in order to satisfy the original request, or an object
supplied to object A as an argument of the message requesting the
service - that is, it is not an object currently residing inside
object A's encapsulation barrier. This definition correlates nicely
with the Law of Demeter... <snip>

Object B becomes the _collaborator_, a covert assistant to object A.
The exchange between object A and object B occurs inside the
encapsulation barrier of the object. It's this covert aspect that
makes this particular exchange different from all other object-object
messaging. Collaboration is an aspect of _how_ and object satisfies a
request."

Point 3) above seems to be extremely limiting (a lot more so than the
Law of Demeter). The way I read it, Object A has to create Object B
"from scratch" from within its currently executing method and the life-
span of Object B will be limited to that method only. Is this
correct?

Thanks,
Lars


From: Daniel T. on 13 Jan 2008 09:48
lars_oberg(a)hotmail.com wrote:

> [David West] contends that the vast majority of people purporting
> to do OOP are really only writing procedural code inside of classes
> (because they never really understood the philosophy and ideas
> underlying OOP).

The procedural paradigm is quite powerful, many times it is all that is
needed. There is nothing wrong with that. On the other hand merely using
a well designed OO framework, forces the developer to use good OO
practices at least at some level.

> > To learn object-oriented programming as conceived by the one �
> > who coined the term �object-oriented programming�, learn �
> > Smalltalk or Squeak.
>
> Yes, I have actually been considering learning Small Talk to better
> understand the ideas of the people who created OOP (like Kristen
> Nygaard and Alan Kay), but since this is a dead or dying language
> (at least for new projects in the non-academic world) I don't know
> if it will be worth the effort.

Then learn Python or Ruby. SmallTalk isn't the only highly dynamic,
late-binding language.

> In a late-binding language / environment, you probably often don't
> have compile-time checking to make sure the messages you send to
> objects are defined on these objects, so the message would be a
> simple string that the object would then check against its defined
> methods to ensure it is a valid message. Do I have that straight?

Yes. This has its pros and cons, on the one hand, it means that a class
designer need do very little to make his class extensible. On the other
hand, it means that less of the design work is outlined in the code
itself (because interfaces are completely unnecessary in such languages.)

> I have one more section from the book that maybe you (or someone) can
> help with as well:
> " 'Collaboration' and 'collaborator' are terms referring to a
> particular type of object cooperation and the object relied upon for
> that cooperation. <snip> Collaboration occurs when
> 1) Object A receives a request for one of its advertised services.
> 2) While in the process of satisfying that request, it needs to ask
> for a service from object B
> 3) Object B is _not_ an object occypying one of object A's instance
> variables, a temporary variable declared in the method that object A
> is executing in order to satisfy the original request, or an object
> supplied to object A as an argument of the message requesting the
> service - that is, it is not an object currently residing inside
> object A's encapsulation barrier. This definition correlates nicely
> with the Law of Demeter... <snip>
>
> Object B becomes the _collaborator_, a covert assistant to object A.
> The exchange between object A and object B occurs inside the
> encapsulation barrier of the object. It's this covert aspect that
> makes this particular exchange different from all other object-object
> messaging. Collaboration is an aspect of _how_ and object satisfies a
> request."
>
> Point 3) above seems to be extremely limiting (a lot more so than the
> Law of Demeter). The way I read it, Object A has to create Object B
> "from scratch" from within its currently executing method and the life-
> span of Object B will be limited to that method only. Is this
> correct?

No, point 3 above specifically excludes such an object... "_not_... a
temporary variable declared in the method that object A is executing..."
What he is saying is that A needs a B but B is *not* something that the
LoD would allow A to use.

There are six different ways for A to use B. (Riel)

1) B is a parameter passed in with the message.
2) B is provided by some other object C.
(Now we have to ask, "how did A get to the C object?")
3) B is in some sort of globally accessible area.
4) B is created within A's method
5) B is given to A through some other message
and stored in one of A's attributes.
6) B is created as part of the process of creating A

The above quote is saying that a "collaboration" only occurs when A uses
B through means 2 or 3. I've never heard of such a restriction on the
term and I'm not sure what can be gained by making such a restriction.
From: lars_oberg on 13 Jan 2008 13:26
> > I have one more section from the book that maybe you (or someone) can
> > help with as well:
> > " 'Collaboration' and 'collaborator' are terms referring to a
> > particular type of object cooperation and the object relied upon for
> > that cooperation.  <snip> Collaboration occurs when
> > 1) Object A receives a request for one of its advertised services.
> > 2) While in the process of satisfying that request, it needs to ask
> > for a service from object B
> > 3) Object B is _not_ an object occypying one of object A's instance
> > variables, a temporary variable declared in the method that object A
> > is executing in order to satisfy the original request, or an object
> > supplied to object A as an argument of the message requesting the
> > service - that is, it is not an object currently residing inside
> > object A's encapsulation barrier.  This definition correlates nicely
> > with the Law of Demeter... <snip>
>
> > Object B becomes the _collaborator_, a covert assistant to object A.
> > The exchange between object A and object B occurs inside the
> > encapsulation barrier of the object.  It's this covert aspect that
> > makes this particular exchange different from all other object-object
> > messaging.  Collaboration is an aspect of _how_ and object satisfies a
> > request."
>
> > Point 3) above seems to be extremely limiting (a lot more so than the
> > Law of Demeter).  The way I read it, Object A has to create Object B
> > "from scratch" from within its currently executing method and the life-
> > span of Object B will be limited to that method only.  Is this
> > correct?
>
> No, point 3 above specifically excludes such an object... "_not_... a
> temporary variable declared in the method that object A is executing..."
> What he is saying is that A needs a B but B is *not* something that the
> LoD would allow A to use.
You're right.

> There are six different ways for A to use B. (Riel)
>
> 1) B is a parameter passed in with the message.
> 2) B is provided by some other object C.
>    (Now we have to ask, "how did A get to the C object?")
> 3) B is in some sort of globally accessible area.
> 4) B is created within A's method
> 5) B is given to A through some other message
>    and stored in one of A's attributes.
> 6) B is created as part of the process of creating A
>
> The above quote is saying that a "collaboration" only occurs when A uses
> B through means 2 or 3. I've never heard of such a restriction on the
> term and I'm not sure what can be gained by making such a restriction.- Hide quoted text -
I guess 4 would be ok as well: New B().DoSomething() from within A's
method as long as you do not use a temporary variable.
Re. 3 above, it sounds like a static factory / singleton or similar.

Anyhow, thanks for taking the time to help me.

Lars


 |  Next  |  Last
Pages: 1 2
Prev: object level locking and class level locking
Next: Business objects, subset of collection