[CFCDev] SimUDuck app from Head First Design Patterns in ColdFusion

[Dave Shuck]

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 cfcdev@cfczone.org 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/cfcdev@cfczone.org