I think Scott's point is well made. I am trying to skip the painful stages on the Developer (Object Warrior) ->. . ... -> Developer path, by writing a simple, generic controller that is useful for everything from the slightly-more-complex-than-usual job to the way-more-complex-than-usual job. I only hope that whoever inherits it will not curse me :-)
I am starting with conventions for the controller cfc name, preserving state and using the idea that the existence of a variable means one thing and its value (if any) means something more specific. Date: Tue, 24 Jun 2008 21:04:01 -0700 From: [EMAIL PROTECTED] To: [email protected] Subject: [cfaussie] Re: CFC Design Patterns Developers typically are pattern experts, they identify a problem and seek a solution that conforms to a pattern that suites them. The more patterns you absorb, dissect and recycle the more you continue to innovate and as such the bar or baseline form where you once were has moved. Ask any coldfusion developer on this list and get them to show you code they wrote in 1998 vs. today and they'll throw statements like "oh yeah, it's bad, but now I'm better" – some declare this the magic of "learning" or "with age comes wisdom", yet what's really happened here? Firstly each developer goes through this growth pattern, as once they can separate the difference between "IS-A" and "HAS-A" they in turn begin to appreciate the ideas associated with OO programming. I remember watching the entire CF industry react to CF 5's existence, with guys like Sean Corfield constantly pushing the various folks within the industry to embrace OO and stop writing stupid solutions (thinking on it, Sean has done a lot for CF). Once OO has been discovered, they eventually move onto Framework appreciation stage. They typically will first road test someone else's code or many of them, that is until they get weary of following behind someone's tail lights and decide to write their own. "I could do this a little better is what echoes through their minds..In that deep dark secret area.." They begin to write, they'll most likely hand out or get their peers to use it, but overall they still haven't discovered fully the design patterns approach to frameworks (Methodology vs. Frameworks). That is until they decide to research how Java folks do xyz or maybe even .NET (choose your own muse). This is when the design patterns begin to creep into the conversation, and before you know it they are reading Martin Fowlers J2EE Design Patterns catalogue which is freely available online. Now they have true religion… this is the scariest but most necessary part of a developer's career. This is where they'll happily embrace the idea of writing 115 Lines of Code to write Hello World, as in the end this is about abstraction and separation of unnecessary tightly coupled objects or domains for the greater good of that which is design patterns. What was the problem being solved again? Who cares, did you not see how I wrote this kickarse observer pattern in my collections/structs? This is when the senior developer in the room needs to step up, assess the situation and take the design pattern pup under his/her wing. It's time they showed them the path to immortality, the path in which you daily use a framework + design pattern but do so in a way that you don't think. As this is when you eventually will lead into the path of learning the one fundamental lesson of all. The best code written is the code you don't write. You may lose a job or two in the process of getting to this point, but you'll eventually figure out fast that 115 lines of code may win you a prize for pure OO solutions being delivered, but writing hello world in 2 lines lets you ship faster. Developer (Object Warrior) -> Snr Developer (Framework Fan) -> Programming Analyst (Design Pattern Zealot) -> Architect (Field Commander) -> Developer. The cycle is brutal but necessary. Still want to write a framework? On Thu, Jun 12, 2008 at 3:41 AM, Kevan Stannard <[EMAIL PROTECTED]> wrote: Hi Adam Head First Design Patterns is a great book, but if you are quite new to OO concepts then it may be a bit of a difficult read. The examples are in Java so basic exposure to the language would certainly help. To get the most out of it you should first have an understanding of OO concepts such as inheritance, interfaces and abstract classes (and their syntax in Java). You might also like to have a look at Brian Rinaldi's OO resource list. There are a couple of presentations referenced there (Matt Woodward, Sean Corfield) that might get you off to a good start. http://www.remotesynthesis.com/blog/index.cfm/2006/7/18/Objects-and-Framewor ks--the-Big-Resource-List -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Chapman Sent: Thursday, 12 June 2008 3:47 PM To: [email protected] Subject: [cfaussie] CFC Design Patterns Hi All, I am looking at re-vamping the way I build cfcs and want to move to a more OO approach.. I have recently started using coldspring and am after pplz thoughts on their favoured design pattern and how best to organise cfcs.. Any feedback or links appreciated.. Regards, Adam Chapman Portplus www.portplus.com T: 03 9800 7777 -- Regards, Scott Barnes http://www.mossyblog.com _________________________________________________________________ It's simple! Sell your car for just $30 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" 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/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
