> Example code alone does not teach a pattern! Completely agree, which is why I did not provide an explanation, and was hoping to get feedback from people familiar with the pattern. The link was just to give an idea of what its all about, I actually read about the pattern in another book.
Anyway, I'll go and hide in my corner again and discover the world of design patterns on my own again, I lost all hope to discuss some of this wonderful stuff on the cf list and port the patterns to cf for all to enjoy ;-)) -- Taco Fleur Senior Web Systems Engineer http://www.webassociates.com -----Original Message----- From: Sean Corfield [mailto:[EMAIL PROTECTED] Sent: Tuesday, 4 January 2005 8:57 AM To: CF-Talk Subject: Re: Typesafe enum design pattern (another go) On Tue, 4 Jan 2005 08:32:06 +1000, Taco Fleur <[EMAIL PROTECTED]> wrote: [singleton] > OK, any ideas on how to make it less complex? > Which part of it did you consider to be complex and why? Umm, I don't remember now... beyond just thinking "Wow, that's a really complex solution to what ought to be a simple problem". > When I read up about the design pattern in Java this was the closest I > could get it to the real thing. > (link: http://www.javacamp.org/designPattern/enum.html ) Right, but that doesn't mean that the same implementation makes sense in CF. > > You also aren't explaining what problem you're trying to solve with this. > I was hoping to get some feedback from people that are familiar with > the design pattern, Well, some design patterns are language specific and the problems they solve don't always translate to other languages. I think it's a mistake to focus on a design pattern in isolation of how it should be used or, rather, what set of problems it is trying to solve. I just posted this in my Breeze room as an example of why code != pattern: Examine the relative importance of sections in a pattern description (from the GoF book): FACTORY METHOD Intent... (a paragraph) Also Known As... (one name) Motivation... (a full page!) Applicability... (when to use it) Structure... (one small diagram) Participants... (a few bullets describing each class) Collaborations... (one sentence) Consequences... (almost TWO PAGES!) Implementation... (describes several implementation options with a few code fragments - three and a half pages - note that this is a set of guidelines for implementation, not a *specific* implementation) Sample Code... (just under two pages of simple code with commentary) Known Uses... (half a page) Related Patterns... (a few paragraphs) The Motivation, Applicability and Consequences sections are the most important. The (long) implementation section contains a lot of theory and suggestions. Patterns are generally light on code and heavy on the whys and wherefores. -- Sean A Corfield -- http://www.corfield.org/ Team Fusebox -- http://www.fusebox.org/ Breeze Me! -- http://www.corfield.org/breezeme Got Gmail? -- I have 6 invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - New Atlanta http://www.newatlanta.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:189191 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
