This is just a reply to Henry, Shawn and Dave regarding my earlier posting on this topic, but as it's longer than 4kB, I cannot post it as a comment to the original post, so I'm creating a new one.
Hi guys. I didn't reply to the bulk of this last night cos I was watching a movie(*) and could multi-task enough to keep an eye on the #ColdFusion channel on Twitter, but not enough to give my reply to you the attention it warrants.
@Henry. Yeah, I too am let down by the lack of static methods in ColdFusion, and for the same reason. I have hit Adobe up about this a coupla times (for CF9 and for CF10), but I'm always swamped by colleagues saying it's to complicated to implement (this was not from Adobe, but a CF community member, so dunno if that has merit); most CF developers are too "junior" to understand what they are so it'd be wasted on them; you can work around it easy enough; ColdFusion is all about simplicity, and this concept is to complicated; and that old specious chestnut "if you want to use Java, use Java". Which is all a mix of faulty logic or is just plain facile. Still: the idea always garners this negative criticism, so I guess it didn't seem compelling to Adobe. Anyway: we are where we are... no static methods.
That said, I'd still not approach it the way you are choosing to, as it sounds really clunky to me. If a CFC needs a utility component, and needs it regularly: just instantiate it in the init() method or pseudo-constructor. If you call your Util.cfc instance variables.Util, them you can call its methods via Util.method(), which is the same as if Util.cfc's method() was static anyhow.
If you don't like having this sort of inter-component dependency (which people get all het up about more often than makes sense, I think), then pass an instance into the init() method and use ColdSpring or something to handle all the ensuing dependencies.
For a util component, I'd probably go "damn the dependency, I need it, and I need it here" and just instantiate it in the pseudo-constructor. If it was less of a "bag-o'-functions" and more of a proper object (if that makes any sense), then I'd probably pass it in. Using ColdSpring (or equivalent).
I know what you mean by the ColdSpring approach causing a large code-separation between instantiating objects and actually using them, but I think its a cost of doing business. And these observations that wise people have made "that it's best to keep code creating a variable close to where you're using the variable", isn't a law, it's just a guideline. And it should not be slavishly adhered to like it's the 11th commandment (or is that 614th? Depends on which version of The Book you read, I guess).
Now, @Shawn. Whilst I disagree with the conclusions Henry arrives at, I think its his prerogative to weigh up the considerations and then make an informed decision. I'm pleased that I seemed to have answered his questions, and on that basis he's decided on his approach. I see nothing wrong with this. I think often people get too hung up with the broad notion of "best practices", and forget about "best approach for a given scenario". Henry's decided this is the best approach for his given scenario, and he's got more information about his given scenario to hand that we do, so I'd not be presupposing he's wrong, just like that.
@Dave: always a pleasure to read your take on things mate. Keep 'em (and me too, obviously) honest :-)
Anyway, it's a rare nice day in London, after the recent Genesis-esque rain we've been having recently, so I'm off up the road to Epping Forest to hug trees and talk to deer. I'm still mulling over what today's "real" blog post will be, and should have decided after a few hours trotting about in the woods.
Cheers.
--
Adam
(*) David Fincher's rendition of "The Girl with the [... Overrated Story]". The movie was finely crafted - David Fincher can direct! - but the story is as overrated as the book and the original Swedish movie was. That said, Daniel Craig and especially Rooney Mara were really good in it.
