Hey Dave, This is really cool! Mind if I blog the URLs and quote your mail?
-Joe 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] -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.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]
