Wednesday, December 22, 2004

Exercises in Design Patterns

I had a really eloquent version of this post all worked out, but for some reason it choked when I submitted it, so this will be a less eloquent, abbreviated version.

Apologies that I've been in a cave lately. I've had the typical end-of-the-year project pileup to dig out from under, but in the course of working feverishly on some of these projects, I've taken the opportunity to take a much closer look at some design patterns, specifically in my case DAOs and how to use them better and more effectively.


I've been using DAOs in Mach-II projects for quite some time now, and although it's been working great I realized I've been using them a bit prescriptively without *really* digging down deep and understanding all the surrounding issues, gotchas, and possibilities. So I've been reading, researching, and reading some more over the past few weeks and I'm starting to have some revelatory insights on some things.

The purpose of this post isn't to share any insights--they're far too half-baked at this point, but you better believe I'll be sharing in the very near future. I'll be thinking out loud and talking to myself a lot over the coming weeks, so please don't be alarmed. I'm not insane, I'm just obsessed. :-) I do think it's appropriate for me to make a few general comments at this point, largely brought on by the introspective season we're in.

First, always be challenging yourself. I'm at the point now with a lot of more advanced OO concepts that I feel like I'm at least starting to "know what I don't know," and it's really inspiring me to go nuts with learning this stuff. I've already looked back and stuff I've written over the last year and seen how much better I could have done things had I known then what I know now.

Second, I'm a bit surprised at the lack of comprehensive CF-specific code samples and literature about OOP and design patterns. It's starting to emerge on some really great blogs (I'll post links later--it's late and I'm beat), but I'm going to do what I can in the coming year to contribute to this area, which I feel is pretty lacking. Since I have a Java background I've been getting a lot out of reading the Java materials, but if we as CFers are going to take our craft to the next level and bring others along with us (kicking and screaming if necessary!), then I think we need our own set of knowledge and literature.

Finally, I'm in the process of rebuilding the Dallas/Fort Worth ColdFusion User Group web site, and I'm going to apply as many of these concepts as I can to this project. For the purposes of the site a lot of it may be overkill, but these sorts of projects are perfect for applying theories I may not have put into practice yet. Once I get the site in a better state of completion I'll share the code so others can learn from it (or rip it to shreds as the case may be!).

Happy Holidays CFers, and if you haven't made the commitment to start doing OOP yet, make 2005 the year in which you do it. Seriously. Not only is it a necessity from a career standpoint, it will make your development life easier and more fun, I guarantee it.


Can't wait to see your interpretation on the patterns with CFMX ( I mean that in a good way). I also think the reason you don't see OOP Patterns discussed in the context of CFMX, is because its regarded as a "Nice Object approach to procedure code". Thats what a lot of the purists have worded to me about anyway, saying its not even *REAL* OO - debatable. So yeah, J2EE seems to be a main source of mirrored conceptulizations which sux as you kind of need to know Java in many ways to understand it. I think we should all (blogs I mean) finalize one big uber blog-fest for 2005 on the subject, and PDF for the future CF'ers heeheheh...

Thanks Scott--I've certainly gotten a lot out of your conversations in Sean's Breeze room as well as from your blog. I definitely agree with the notion that we need to ban together and blog the heck out of this stuff, and I've already thought about a series of articles (instead of just blog posts) for distribution as PDF (or FlashPaper! go MM!) so it's a bit more easy for folks to take it along, print, etc. Once we all reach a consensus on everything (or even have 2-3 "best practices" for each of these areas) I think it will prove to be a great resource for CFers. Blog posts and subsequent comments (great place for us to hash out the details) can serve as great fodder for more formalized documents, tutorials, etc. (And let's not forget those who are OO newbies, because these are numerous with CF; OO-101 stuff would be extremely valuable in addition to more advanced topics.) On that point, the other thing I think CF literature does a poor job of is indocrinating people into OO from the start. Yes, CF is intended to be easy to learn, etc. and I don't think CF should lose that strength, but I think a lot of CFers don't get into OO because it's presented as "advanced" or "that weird other thing that a handful of people do." Once people get their feet wet with CF syntax, etc., OO should be presented as "the way you should be building things." In my opinion it's not gaining traction because it's seen as unnecessary or esoteric. Opening people's eyes to the huge advantages and presenting it as how you do CF will help in this regard. As for whether or not CF is "real OO," you're right, that's debatable. I don't typically engage in that debate because there's no denying CF is missing some hallmark features of true OO, but in my mind nitpicking kind of misses the point. (Not saying you do this, but some folks do.) Let's push things and do as much as we can with what we've got rather than not doing OO at all because this or that can't be accomplished in CF.

No comments: