On 7/10/07, Andrew Scott <[EMAIL PROTECTED]> wrote: > When learning design patterns in Java, the book Head First Design Patterns > gives a good example on the duck, with interfaces and implementation.
Right, in *JAVA*. If you look at the classic Design Patterns book - the so-called "Gang of Four" book - you'll see they use Java and *Smalltalk* as their two languages for examples and of course Smalltalk does not have interfaces. Interfaces are required in Java because it is a statically typed language that does not implement multiple inheritance. That's the only reason interfaces exist in Java. > After reading this book, I see that when creating interfaces I can create an > object and know that these methods are going to exist for the object. In *JAVA*. You're thinking in Java so you're totally missing the whole dynamic typing issue. I'll say it again: Smalltalk and Ruby do not have interfaces - they are dynamically typed languages. ColdFusion - a dynamically typed language - does not need interfaces either. > So if we take the duck example in the book, how would you apply this in > Coldfusion without using interfaces? Since I don't know that book, it's hard to show how I would apply it in CF or Smalltalk or Ruby. Doing the search that Neil R-R suggested turned up Dave Shuck's blog post so now I see that we're talking about the Strategy design pattern and he provides a possible solution (I haven't looked at). There are two types of approach in a dynamically typed language: 1) use a base class that defines the necessary methods but have them throw exceptions (i.e., cause a runtime error if they are not overridden) 2) simply use type="any" and allow any strategy object to be pass in - if it doesn't implement the right methods, you'll get a runtime error In #1, you get a runtime error if you don't override a method - an application exception - but you are forced to have all your strategies extend a base strategy class. This is the closest to using an interface and is the pseudo-static approach. I don't like it. In #2, you get a runtime error if you don't provide a method - a ColdFusion exception - and you are no longer tied to a base class which means you can take pre-existing behaviors that know nothing about your specific context and reuse them as-is. In other words, through duck typing you get better reuse and no worse type security. With <cfinterface> you'd have a solution that looked like #1 but gave a different runtime error - either your concrete strategy implements the strategy interface or it fails at create time; or of course you get the runtime error passing a "non-strategy" object into the context. #2 is more powerful (and is how you'd handle this idiomatically in Smalltalk and Ruby). Of course the duck example is a bit too simplistic to show how much more powerful the dynamic approach is but I will point out that it lends itself to mixins where you can construct the appropriate blend of strategy behaviors at runtime, perhaps based on information in a database, in a way that simply isn't possible in the constrained world of #1 (or interfaces). Hope that helps? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion?sdid=RVJW Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:283470 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
