On Nov 23, 2007 9:47 AM, Alan Livie <[EMAIL PROTECTED]> wrote: > > Thanks Sam for your comments. > > > > > Going over each pattern as a refresher, it looks as if they are the same > > with slightly different contexts and intents. > > I guess choosing between the two is only a contest for whose name gets > to be > > used, then. > > How would your code or idea you mentioned above change if you decided to > go > > with Strategy? > > > > Yes I agree. Strategy does sound like a better name because I now > realise with State an object is almost expected to change its state by > itself depending on some actions. In my case it wouldn't need to. It > would have its behaviour set by client code so Strategy does actually > make more sense. Thanks for suggesting it! > I also agree the classes don't differ between the two but naming is > important so others in the team get a clearer idea on what's > happening. > > > > Anyway, for me, I think it makes more sense to speak of > > UserValidationStrategies than UserValidationStates, but really, I'm not > sure > > it makes a difference in the code, only how we communicate about it. > And, > > as long as no one is going to get religious about it one way or another, > > just making a decision on what to call it and sticking to it is probably > > just as good. > > Yes. I'm convinced. Strategy it is. I knew they were similar but after > having a look at the UML for both patterns I can now see they are the > same. It's the methods and internals of the cfc's themselves that > differ:
Don't be too convinced - I'm certainly no "patterns guru!" =) Perhaps the others will chime in with their own opinions and offer something different. I certainly can see a case made for State, but my own preference would be to call it Strategy, that's all. Sam > > > ie in State the instance variable is changed to the relevant concrete > state object depending on what method is run from either the context > object or another one. Also, each concrete State object is set as an > instance variable in the context object as the superclass/interface's > type. > > with Strategy once I create the object and tell it what behaviour it > should use it will stay that way (in this scenario at least but I > accept not always in other implementations). And the context holds a > reference to the abstract Strategy cfc, not references to the concrete > sub-classed strategies. > > However, the above explanation is from a patterns newbie and based on > a couple of examples I have seen so I could be completely wrong on > this. I'm happy for a patterns guru to correct me on this! Don't > worry, I wont update wikipedia with my explanation :-) > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" 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/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
