> You've created a situation where introducing an object that's not
> initialized the same way is painful. So instead of doing the right
> thing, you may be tempted to force your object to intialize the same
> as all the others. Otherwise, you have to introduce a -- *gulp* --
> special case.
I'd disagree. I've created a situation where it's sometimes easier to
introduce a new object. I gotta write a getXXX() method anyway, just
sometimes I get to skip it.
> Also, aren't you a fan of strong typing? What do you make the
> returntype of a method that returns lots of different types?
Yes I am, and an abstract superclass meets this need very well. An
interface would be better for certain things, but in general it works
well enough with out it.
> <cffunction name="createBarGateway">
> <cfreturn createGateway("bar", variables.dsn)/>
> </cffunction>
>
> Only this way you don't need a switch statement.
Yeah, I suppose that'd work just as well. Interesting how there's
always to multiple to skin a cat (I prefer head to tail).
> What's going on here? We drag someone through the mud for
> advocating get(fieldname) and set(fieldname, value). Then Hal
> does the same thing with his isNull(fieldName) method. Now
> you and Nando are getting into the game.
I thought I was perfectly clear in stating that the design goes
against convetional wisdom. You illustrated above a better way to go
about it. I'm not against it for the 'lots of public methods', or
whatever other reason, I just happen to like
gatewayFactory.getInstance("user") rather than
gatewayFactory.getUserGateway(). And I certainly wouldn't go blindly
applying the same design to other scenarios.
cheers,
barneyb
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
----------------------------------------------------------
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]
