I agree Matt, I think it would be a great topic and I would be happy to do it.  Given all the good stuff coming up on our calendar the next few months, I guess we can look at March.  It is a great problem to have too much good content! :)

And to the others who said 'thanks', you are welcome.  I am glad someone else thought it might be helpful.  I know it certainly was for me.

~Dave

On 12/11/05, Matt Woodward <[EMAIL PROTECTED] > wrote:
Dave, you realize you inadvertently have volunteered yourself to do a
talk on design patterns at the DFW CFUG now, don't you? ;-)
Seriously though, thanks for taking this effort and if you would like
to present at a meeting, just let me know.  I think it would be a
great topic.

Matt

On 12/11/05, Montreal <[EMAIL PROTECTED]> wrote:
> Hey Dave,
>
> I have been working my way through the book also. It is great that you wrote
> the examples in CF.
>
> Thanks,
> Montreal
>
>
>
> On 12/11/05, Dave Shuck < [EMAIL PROTECTED]> wrote:
> > As I make my way through Head First Design Patterns , I decided I would
> work out some of the exercises in ColdFusion code.
> >
> > The opening chapter deals with an imaginary SimUDuck application,which
> gives a great example of the Strategy Pattern.  I am not going to go into
> great detail on the chapter, but it deals with not only the benefits of
> object inheritance, but the problems as well.   I have produced ColdFusion
> versions of 4 stages of the SimUDuck application which follow along with the
> chapter.  This might make a nice companion for someone reading that would
> like to see how this implemented in ColdFusion.
> >
> > Even if you haven't read the book, the code is fairly straight forward,
> and you hopefully will see how the solutions are implemented.
> >
> > Also, these concepts are still fairly new to me so if someone sees
> something I did that's goofy, please let me know.  I plan on giving this as
> a class to my group at work next week and I don't want to pass along bad
> habits. :)
> >
> > Step 1: Starting the SimUDuck App
> > First, the simple SimUDuck app contains only 2 types of ducks which are
> subclasses of the Duck class.  Each duck subclass implements its own version
> of the display() method.
> >
> > Step 2: New requirement!  Ducks need to be able to fly.
> > No problem!  Since the ducks inherit the methods of the Duck class, we can
> solve this problem by just adding a fly() method.  Whoops!  Someone just
> added a Rubber Duck to our system.  Rubber Ducks can't fly!
> >
> > Step 3: Fixing our flying Rubber Duck problem
> > We solved our flying Rubber Duck problem by just adding a fly() method
> within the RubberDuck class that did nothing.  This overrides the fly() in
> the Duck superclass.  We also added a quack() to the application.  Since
> Rubber Ducks don't quack, we implemented a separate quack() that squeaks in
> the RubberDuck class.  So problem solved... but now we have added a Decoy
> Duck to our application.  This duck doesn't fly or make a sound.  Again we
> overrode the Duck methods, but we are beginning to see what a maintenance
> nightmare we are creating.
> >
> > Step 4: Encapsulating the Behaviors
> > We have now encapsulated the fly() and quack() behaviors into their own
> groups of classes or "families of algorithms". Then each instance of the
> duck object can have their own instance or whichever behavior is appropriate
> to them and are contained in their FlyBehavior and QuackBehavior properties.
> By doing this, a duck class is not locked into a specific type of behavior
> and these behaviors can easily be altered at runtime. Additionally, if we
> suddenly add a new type of flying behavior, it is as simple as adding a new
> subclass to the FlyBehavior group.
> >
> > Hope this ends up being helpful to someone else.  I know working through
> it was helpful to me.
> >
> > --
> > ~Dave Shuck
> > [EMAIL PROTECTED]
> > www.daveshuck.com
> ----------------------------------------------------------
> > You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
> >
> > CFCDev is run by CFCZone ( www.cfczone.org) and supported by CFXHosting (
> www.cfxhosting.com).
> >
> > An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
> --
> Montreal
> ----------------------------------------------------------
>
>  You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
>  CFCDev is run by CFCZone (www.cfczone.org ) and supported by CFXHosting
> (www.cfxhosting.com).
>
>  An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]


--
Matt Woodward
[EMAIL PROTECTED]
http://www.mattwoodward.com


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]





--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

Reply via email to