Whether you are an oMM() fan for the dumb getters and setters or not, a good 
principle in OO is to NOT think about performance first - yes it is important 
but not if it affects your design in a negative way.

I'm sure it was Martin Fowler in his Refactoring book that uses the refactoring 
'Replace Temp With Query' that talks about the performance issue. 
http://www.refactoring.com/catalog/replaceTempWithQuery.html

This is a good refactoring for cleaner, more readable code BUT may cause 
performance problems if the query (not a cf-type query - just a method that 
returns something) does intensive work (ie hit a database)

He makes the point that ONLY IF you see a performance problem as a result of 
this refactoring should you refactor back into using temps.

In an example that the query did talk to a db I would probably keep the temp 
but if its just a method taking some instance variables and doing a calculation 
I wouldn't worry.

When it comes down to a few milliseconds of a performance hit I think you 
should always pick the best design and most readable code rather than saving a 
tiny bit of time. If performance was the driving force in our designs we would 
ignore OO, custom tags, cfincludes etc and write big horrible duplicate 
code-filled scripts! Maybe a bit extreme but you know what I mean :-)

 Alan




________________________________
From: Brian Kotek <[email protected]>
To: [email protected]
Sent: Sunday, February 1, 2009 2:04:36 AM
Subject: [CFCDEV] Re: Questions on Design of Bean, what is your version  like?

Yes, I'm positive. Having the functions compiled to Java at compile time will 
ALWAYS be faster than dynamically evaluating the function at runtime. Though 
the fact that it's slower isn't the main reason I prefer real getter and setter 
functions and I doubt the difference is very large unless the oMM is performing 
a great deal of processing or metadata parsing.


On Wed, Jan 28, 2009 at 1:33 PM, Henry <[email protected]> wrote:


Are you guys certain that oMM will be always less efficient?  Didn't
creation (and attaching) methods into an object is also expensive in
CF8?  Since beans needed to be created all the time, maybe the cost of
creation of methods will offset the slightly inefficient oMM?  I guess
performance should not, in theory, affect how we construct our code,
but at some point it does.




      
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to