On Thu, 20 Jan 2005 06:32:10 -0800, Joe Rinehart <[EMAIL PROTECTED]> wrote: > I get it, light bulb, it's letting another class decide what actually > gets instantiated, and because that class doesn't need to be a > concrete Thingy, just something that implements what a Thingy is, we > just became more flexible by not relying on a concrete but an > abstract..right?
Yes. Delegation and abstraction help reduce coupling and make your program easier to maintain / extend / revise. > I'm a little confused, though, as to handle polymorphic concerns in CF > without it. True, polymorphism in most languages relies on inheritance or interfaces which makes some things a bit harder in CF... > It's why I've been moving more towards having > "FooThingy" and "BarThingy" agree, on paper, in some other document, > or simply in my head that they will both implement a doSomething() > method, and having GetThingy() return Any. Programming by contract. It's an OK way to look at it. Obviously it would be nicer if the language provided more support but, hey, you don't *need* language support to implement it... -- Sean A Corfield -- http://www.corfield.org/ Team Fusebox -- http://www.fusebox.org/ Breeze Me! -- http://www.corfield.org/breezeme Got Gmail? -- I have 5 invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
