Howdy Patrick! I liked the dragging us through the mud part!
I don't know if i'm dragging anyone with me, i hope not ... but most of the time i am standing knee deep in it in trying to understand OO design. Here's my take on the thing. I learn as much or more from my mistakes, from walking through the muddiness of my own attempts at OO oriented design, as i do from just following something shown or done correctly, even if i do so with my eyes wide open (not blindly, in other words). I think Joe said it well, that you don't understand a pattern until you suffer the pain that it's meant to solve. I'm trying to understand what it means to code to an interface ... how far to take that, in which directions it might work best. And i'm all alone here, working on my own. So everything i do is pure trial and lots of error. I understand that it doesn't mean to code to a single "do" method. But i also understand that to code to an interface often implies that many of your methods are private - that how an object gets it's work done is hidden from the rest of the application and not intertangled with it. Where's the balance? One of the problems with my application designs up til now is that they are too tangled, things are too coupled. And when a client calls and asks for a change, typically i need to change the same thing mirrored in several objects. Or it takes time to follow the trail of things i need to change through the whole app, because one thing affects the other. I'm feeling the pain of my inability to consistently design to an interface. So I'm trying to teach myself. >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Patrick McElhaney >Sent: Thursday, November 03, 2005 11:15 PM >To: [email protected] >Subject: Re: [CFCDev] Factory Pattern > > >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] > > ---------------------------------------------------------- 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]
