Dave,
Thank you for making your hard work available to the
public.
I just ordered Head
First Design Patterns as well, and will be looking forward to seeing the
theory in practice.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Shuck
Sent: Sunday, December 11, 2005
2:48 AM
To: [email protected]
Subject: [CFCDev] SimUDuck app
from Head First Design Patterns in ColdFusion
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
----------------------------------------------------------