Thanks very much for the replies. I had assumed that it was going to be pretty much a case of practice / familiarisation.
Though I did find this - which is helpful for my purposes... http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Gavin. On May 10, 6:16 am, Sean Corfield <seancorfi...@gmail.com> wrote: > On Mon, May 9, 2011 at 1:06 PM, Sean Corfield <seancorfi...@gmail.com> wrote: > > A design pattern includes "forces" and trade offs so several design > > patterns might apply to address a specific problem and which one you > > pick would depend on which trade offs you wanted to make. > > And it's also worth pointing out that some design patterns are > language specific or at least apply more to certain languages than > others. Books like Core J2EE Patterns include quite a few generic > patterns but also a number of patterns which solve problems that are > caused by Java itself. Singleton is a good example of this. The core > of the Singleton pattern is global access to a known, single instance > of an object, with a single well-defined point of initialization. This > is *incredibly* hard to achieve correctly in Java (in a fully thread > safe manner) but it's something we have built into CFML: > Application.cfc: onApplicationStart() - well-defined, thread safe > point of initialization; application scope - easy global access to the > single instance, created in onApplicationStart(). > > All the rest of the nonsense you see in Java implementations is > because Java forces everything to be a class so the only "global" way > to access an instance is via the class name and therefore a static > method - and then you get all the nasty thread safe initialization > issues cropping up. Java doesn't have any concept of "an application > starting up". > > So you need to be careful when reading design pattern material - a lot > of it is fairly Java-centric, at least in its implementation (Gang of > Four excepted of course, since it uses C++ and Smalltalk for > examples). A lot of people think you need interfaces to implement > design patterns but Smalltalk does not have interfaces (and C++ > doesn't either, at least not in the way Java has them). Java > interfaces are an artifact of the way the Java language was designed > and some of the dogmatic decisions made early on not to "follow" C++. > In a dynamic language like CFML, many design patterns become somewhat > unnecessary or have much simpler implementations. It's also worth > pointing out that not much has been written about design patterns for > truly dynamic languages yet: metaprogramming is a very powerful > technique that provides a radically different way to approach some of > the "traditional" design patterns as far as implementation is > concerned. > > At the risk of sounding my own horn, you might want to read my Design > Patterns presohttp://corfield.org/blog/page.cfm/presentations(or > watch one of the several recordings - where I tend to go off on rants > about what can go wrong when you slavishly follow design patterns :) > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View --http://corfield.org/ > World Singles, LLC. --http://worldsingles.com/ > Railo Technologies, Inc. --http://www.getrailo.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
