onMissingMethod() is effectively a way of implementing get("FirstName")
while still keeping the syntax of getFirstName() in your calls. I don't
think there are two camps that can't agree between get("FirstName") and
getFirstName() so much as two different approaches that are better for
different classes of use cases.
The biggest downside with onMissingMethod() or get("FirstName") is that your
code is much less self documenting. If you're working in a team and/or have
new people coming and going on a frequent basis, having the actual classes
within your beans for getting and setting properties will make it very clear
to them how everything works. That said, if they're used to
dynamic/lightweight programming approaches, it wouldn't take them very long
to "get" your approach using get("X") or onMissingMethod(), so the skill
level of your team will be a factor here.
Another benefit of physical methods is that it makes it easier to use
standard tools to generate documentation from your code and for
introspecting frameworks to do clever things with your code. It may also
have a performance benefit, but I'm honestly not sure whether the additional
methods (compiled down to additional anonymous inner classes in Java) would
outweigh the smaller number of function calls - that'd take some testing if
and when there was a performance problem in a given app. My guess is it
wouldn't be the biggest issue unless you had a really tightly optimized code
base, but I'm usually wrong when I try to guess what'll be a real world
performance bottleneck, so who knows - I wouldn't worry about it myself.
I actually prefer using a generic getter to onMissingMethod(). The benefit
of onMissingMethod() is that it decouples your design decision from calling
code. You can switch between onMissingMethod() and generating/writing
getters for each property and the interface (with methods like
getFirstName()) won't change. If you have any doubt about whether to use
generic getters, definitely consider onMissingMethod() as refactoring later
to actual getters will be straightforward (if a little tedious).
The reason I love generic getters over either of the other approaches is
that I'm almost always looping through property name lists. So everywhere
from my form processors to my display templates I have something along the
lines of:
For each PropertyName
Object.get(PropertyName);
Next
This is just syntactically a little easier using CF Script than trying to do
the equivalent if you need to concatenate the property name into the name of
the method. However, I have a fairly non-standard use case, so your mileage
will vary.
Best Wishes,
Peter
On 9/27/07 7:39 AM, "Alan" <[EMAIL PROTECTED]> wrote:
>
> I'm just realising how handy onMissingMethod() in CF8 can be.
>
> I read some of Sean Corfield's blog on this and looked at Brian
> Kotek's ColdMock which uses it too.
>
> My question is on getters and setters.
>
> Some of my business object / bean CFC's have many getters and setters
> (most of them simple). I use the Illudium Code Generator for these
> CFC's (and also looking at the Stub Generator) so it saves me lots of
> typing but wondered if I should just use onMissingMethod() to handle
> this instead and keep the CFC's smaller.
>
> I understand that this is just one simple use of onMissingMethod() but
> wondered what others think of this approach.
>
> I've read stuff on the debate between whats best - getFirstname() or
> get("firstname") and it seems there are 2 camps that can't agree. I
> wonder if onMissingMethod() will produce the same polarised opinions.
>
> Also, what other design issues are people using onMissingMethod() to
> address?
>
>
> Alan
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
