From: Robert Klemme <bob.news@...>
Date: 2006-01-12T20:23:03+09:00
Subject: Re: Looking up properties and speed

David Vallner wrote:

<snip/>

> <rant>
> BUT! Quite a few guides on coding style would say temporary variables
> should be avoided whenever possible in clean OO code and replaced with
> queries (computed property getters).

I don't think that this general rule holds.  A crucial bit to remember -
and that hasn't been mentioned if I'm not mistaken - is that there is a
semantic difference between

obj.foo << bar
obj.foo << baz
obj.foo << buz
obj.foo << bum

and

f = obj.foo
f << bar
f << baz
f << buz
f << bum

This code will behave quite different if

 - multiple instances access obj concurrently

 - obj.foo does not simply return an object but creates a new one for
every call (or even more complex behavior)

It depends on the situation at hand which of the two is the more
appropriate solution.

> And using a temporary variable
> only to cheat the interpreter is plain wrong. Avoid. The speed
> improvement you gain will most likely be next to insignificant, and
> if not, you still should never optimize without profiling the code
> first.

Definitely!

> That said, the code you show is more likely to end up refactored as a
> method of ``obj'', where you could access the instance variable
> directly. A method that only manipulates data on another object indeed
> should be a method of that object.

It depends: this might be taken as an indication to move the method there
but I don't subscribe to this general rule.  It might be the case that the
method doesn't fit the class (i.e. doesn't make sense to be part of the
interface).

> Suggested reading: Martin Fowler's "Refactoring...", a timeless, and
> IMO highly respected classic.

+1

Kind regards

    robert