Re: A Design Problem

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

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote:
On Fri, 24 Aug 2007 16:35:36 -0400, Daniel T. wrote:
Nick Keighley <nick_keighley_nospam@xxxxxxxxxxx> wrote:

Tool class will have all the methods which can be called on
at least one type of tool and have the default
implementation which will just throw some exception.

ah. that frightened me as well. I was thinking a do-nothing
method instead was a good idea, but apparently not.

A do-nothing method is perfectly acceptable, and IMHO preferred.
Just keep in mind, this means the method can have no
post-condition (strictly speaking the post-condition is "true".)

No, this is the postcondition of an implementation for this
*specific* type. The postcondition of the class, will not be
satisfied that easily. Compare this with multiplication by a number.
If the multiplicand is 0 you need not to do anything to get the
result. But this does not mean that it would be same for all other
numbers. Multiplication has "non-trivial" sense even, if it
occasionally is idempotent in 0.

Sorry, your example doesn't make any sense to me, but I can speak to
your generalization.

If objects of type T have a method M, and that method has the
post-condition TRUE, then the only thing *any* object of that type
(including sub-types of that type) need do when sent the message M is to
return control to the sender.

I.e. the postcondition of M on the class T is trivially true.

Nothing else is required of them, and it
is improper for the sender of the message to expect anything more.

= the method M is useless and *shall* be removed from the class T.

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.

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.

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.

The natural question then becomes, why bother calling such a
method? You see, the purpose of the method changes in this case.
You are calling the method to inform the object of something,
rather than to get it to do something.

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. Telling to
object is just a figure of speech. Objects behave in the only possible
(correct) way, they can. All others ways are bugs (incorrect) Objects have
no choice, they are what they are. Being and doing are fully equivalent to
them.

" 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.

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

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

Relevant Pages

  • Re: A Design Problem
    ... this is the postcondition of an implementation for this ... is improper for the sender of the message to expect anything more. ... Informed, sir!" ... tells object B to do X, there is an implied master/slave relationship. ...
    (comp.object)
  • 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. ... informing about something (in order to cause an effect of doing ...
    (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)