Barney,
I apologize. My email was worded too strongly -- especially the tangent part.
Patrick
On 11/3/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
> > 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
--
Patrick McElhaney
704.560.9117
http://pmcelhaney.weblogs.us
----------------------------------------------------------
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]
