🚀 go-pugleaf

abulka@my-deja.com wrote:
> You are right.  Martin Fowler is right.  I am wrong.

Phew... things were getting a little strange there for a while... :-)

[SNIP]
> (All I can say in my defence is that because the Java language
> distinguishes and encourages usage like "Order order _order"
> and "Customer customer _customer", I need to be more careful in the
> future.  In object pascal I am used to TCustomer Customer fCustomer)

Well, to give some concurring feedback, I personally do not like the
'_order' convention and use a different one ('myOrder') on my projects. 
Also, someone to whom I showed the example had a few problems with it
too (although that may be because I printed it with a 6pt font). 
Changing conventions the code would look like this:

    public void setCustomer (Customer customer) {
        if (myCustomer != null) myCustomer.friendOrders().remove(this);
        myCustomer = customer;
        if (myCustomer != null) myCustomer.friendOrders().add(this);
    }

That may or may not have helped...  It may just take a while to get used
to slightly different syntax and idioms.  But another item you
indirectly suggest may have helped quite a bit...

> ... In fact, the
> setCustomer algorithm is perfectly described in the Refactoring book
> text p199: "first tell the other object to remove its pointer to you,
> set your pointer to the new object, and then tell the new object to add
> a pointer to you."

If Martin had factored the method to match exactly what he wrote, we
would instead get:

    public void setCustomer (Customer customer) {
        unlinkFromCurrentCustomer();
        myCustomer = customer;
        linkToCurrentCustomer();
    }

    protected void unlinkFromCurrentCustomer() {
        if (myCustomer != null) myCustomer.friendOrders().remove(this);
    }

    protected void linkToCurrentCustomer() {
        if (myCustomer != null) myCustomer.friendOrders().add(this);
    }

This is now very descriptive, matches the narrative exactly, and is very
unlikely to allow a misreading or miscopying.  Although it would be
somewhat unusual (i.e. not main-stream) to have methods this short in
Java, that is no reason to not use this approach when it would help
readability and maintainability.  The above is a very Smalltalk (i.e.
Superior :-) way of writing code, and I highly suggest getting [Beck 97]
for examples of this type of cleanup.  Although you would have to deal
with another syntax you may not be familiar with, the patterns/idioms
and transformations described in [Beck 97] are universal to all OO
languages.

> Thanks for your patience and assistance,

Your welcome :-)

--Mark
mark.fussell@chimu.com

[Beck 97]  Smalltalk Best Practice Patterns, Kent Beck, 
           Prentice Hall... 1997. ISBN: 0-13-476904-X.