Re: A Design Problem

On Sat, 25 Aug 2007 15:43:05 -0400, Daniel T. wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote:
On Sat, 25 Aug 2007 10:05:25 -0400, Daniel T. wrote:
"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote:

Of course they may do much more than that if they choose, but the
sender of the message has no right to *expect* them to.

Let's clarify it:

A. If under "sender" we understand "public interface," then M shall
be removed.

What? Sender doesn't mean public interface. "Sender" is an object
sending a message to another.

So what? There are very simple questions to ask: does the postcondition of
M depend on the sender's state? Does it on the receiver's one? If not [as
in the case when it is trivially true], then M is not a method of either
<=> irrelevant to either <=> can and shall be removed.

B. If "sender's expectance" is narrower than that, then the
prostcondition of M might be trivially true in that narrower
context, but still untrue for some other clients. In that case M can
have right to exist. However I would suggest it bad design, because
the sender *expects* the effect of M being visible by other clients.

We obviously disagree.

Example, let we send a radio signal to another galaxy. We cannot
observe the effect of this action, and we will be long dead before
other clients (aliens) will receive it (B). That's a bad design,
mobile phone is much better communication tool. But if (A) there
were no aliens then sending signals would pure wasting time and
money = let's send nothing and say we did.

Alternative example. When one ant lays a pheromone trail, it doesn't
tell any other ants to do anything, yet laying that trail is exactly
what is needed.

Needed for *what*? Answer this, and you will have the postcondition.

When you write a program, does that tell anything anybody else? Word games.

Uhm, what is semantic difference between "doing" and "being
informed"? I bet there is no one. The postcondition of the
method is "yes sir! Informed, sir!" I suggest that an informed
object differs to an uniformed one. At least it should accept "I
told you so." Otherwise there were really no sense in having
this method.

"When I tell you to do something, I expect you to do it."

Differently to people, computer objects have no freedom of will.

What does that even mean? You are throwing around meaningless phrases as
if they are important in some way.

Hey, the analogy to a human telling something to another human was not
mine, but yours. I just pointed out that this analogy is flawed, because
any possible difference between:

1. ordering to do something and

2. informing about something (in order to cause an effect of doing
something particular)

is ultimately based on the notion of [free] will, which cannot be applied
to objects. Without free will 1. and 2. are just equivalent.

When object A tells object B to do X, there is an implied
master/slave relationship. When such a relationship exists, B's
responsibility for its own state is reduced.

? I am disagree in so many positions, that I cannot figure out to
where I should start to object:

1. The driving source is neither A nor B, it is the programmer.

2. Object cannot call object. Methods are called. When the method X
belongs to both classes, then roles of A and B are equal.

Neither of the two points above are objections to what I said.

See above. Considering a method M and its poscondition you have to specify
its class. Telling, doing, sending, receiving, masters and slaves are just
meaningless words. Who tells the sun to shine? Why should I care, if it
keeps doing?

3. B's responsibility for maintaining its state is always 100%.
Otherwise it were not OO.

My point exactly!

If so, then what did you mean under reducing B's responsibility? It cannot
be less than 100%, it cannot be greater than 100%. How are you going to
reduce it?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: A Design Problem
    ... this is the postcondition of an implementation for this ... I.e. the postcondition of M on the class T is trivially true. ... is improper for the sender of the message to expect anything more. ... visible by other clients. ...
    (comp.object)
  • Re: Incoming invitation become plain text
    ... Perhaps that sender has your recipient user's Outlook Contact ... "There are seldom good technological solutions to behavioral problems." ... Even the same sender send to other clients in the organization, ...
    (microsoft.public.exchange.clients)
  • Attachment problem
    ... Our site includes Exchange2003 server and Outlook97/xp/2003 clients. ... An e-mail with attachment (Office appl) sent from specific sender to a number of recipients in different organization. ...
    (microsoft.public.exchange.admin)
  • Re: A Design Problem
    ... Sender doesn't mean public interface. ... the sender *expects* the effect of M being visible by other clients. ... object differs to an uniformed one. ... master/slave relationship. ...
    (comp.object)