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 preso http://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.
