It sounds like in your case you'd want to use a factory pattern: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Scroll down a bit on that page to see a description of the factory pattern as it relates to DAOs. In most cases with DAOs they're going to be so different from one another that it doesn't really make sense to use inheritance, but it can help to use a factory to create the DAO you need as you need it. In Mach-II applications I usually put things like datasource info, etc. in the Mach-II config file and call it from there; if you're not using Mach-II you might consider putting this sort of information in your Application.cfm file. That way you're not hard-coding it in any of your objects. Even if you put the same information in two places that's bad compared to putting it in only one! Maybe after we do some basic OO CFC stuff at the CFUG meetings we can get deeper into design patterns, which is what you're starting to touch on with what you're working on. Sun's Java web site has tons of information, and there's also a pretty decent book that just came out called "Head First Design Patterns" (O'Reilly). I'd do some reading and thinking on this stuff before diving into "Design Patterns" (the "Gang of Four" book) but it's the bible of design patterns. Luckily it also has a companion book called "Design Patterns Explained" and they just released a second edition of that. Matt On Wed, 12 Jan 2005 21:17:52 -0600, Daniel Elmore <[EMAIL PROTECTED]> wrote: > Ah, I see error in my design. I guess it would have helped to state what I > was really doing from the beginning. > > I am creating DAOs and wanted all of them to extend to a "master" DAO that > gives them information like the datasource, username and any other > properties they might need. So the variable values are hard coded into the > master DAO, not passed in. Obviously I am using inheritance incorrectly! I > suppose I could write the values into the master DAO's getter methods, ha > ha. Thanks for your reply Matt, I did understand. Hopefully I will use the > extends attribute correctly one day! > > Where do you put information like this for the DAOs you write? > > Thanks again! > Daniel Elmore > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Matt Woodward > Sent: Wednesday, January 12, 2005 8:18 PM > To: [email protected] > Subject: Re: CFC Super.init > > This is a great question and a common point of confusion. (As an > aside, don't use the "this" scope!) > > Here's the short answer, and I can crank out some specific code if > need be to illustrate the point. Basically if you have an init method > in both your CFCs, you'll have to have all the arguments from your > parent CFC duplicated in your child CFC (and passed into your child > CFC) in order for your call to super.init() to work correctly. I'm > not sure the Car and Honda example is the best one to use because > while it's true that you can make the statement "Honda is a Car," > indicating inheritance, Honda would really be an attribute of the Car > object rather than a separate object in and of itself. I'm not trying > to be difficult about all of this, but I'll use a bit of a different > example just to illustrate the point Daniel's getting at. (OO design > is difficult and a separate discussion altogether.) > > Let's say we have a Person object with attributes firstName and > lastName, and that the Employee object extends person, adding among > other things the attribute ssn. So in your Employee CFC, you would > have to include the firstName and lastName arguments in your arg list > even though they're in the object from which it inherits. Odd I know, > but think about it this way: when you create an Employee object, > you're calling the *Employee* object's init method, so it needs to > know about those arguments, and when you call super.init() you're > calling it from the Employee object, and it needs to pass this info up > to the parent object. > > So while it might seem redundant, your Employee init method would look > like this: > > <cffunction name="init" access="public" output="false" > returntype="Employee" hint="Constructor for the Employee CFC"> > <!--- Person args ---> > <cfargument name="firstName" type="string" required="false" default="" > /> > <cfargument name="lastName" type="string" required="false" default="" /> > <!--- Employee args ---> > <cfargument name="ssn" type="string" required="false" default="" /> > > <cfscript> > // call Person's init method using super.init() > super.init(arguments.firstName, arguments.lastName); > // set the Employee object's values > setSsn(arguments.ssn); > </cfscript> > > <!--- return the object ---> > <cfreturn this /> > </cffunction> > > Now what you DO inherit is all the parent object's methods, so you > don't have to duplicate any of those. It's just the constructor that > you have to worry about. > > Let me know if that doesn't make sense. > > Matt > > On Wed, 12 Jan 2005 18:31:57 -0600, Daniel Elmore > <[EMAIL PROTECTED]> wrote: > > I am fairly confused on how the super scope works. > > > > Lets say I have the following: > > - 2 CFCs, one called Car the other called Honda > > - Honda extends Car > > - Car.init sets two 'this' scoped or 'variables' scoped variables > (hopefully > > it doesn't madder in this example) > > - Honda.init calls super.init() > > > > Shouldn't all of Honda's methods have access to the 2 variables set in the > > Car init() method, either directly or via Car's getter methods? If not, > how > > do you get this functionality and is this a common design pattern? Am I > > designing things the wrong way. > > > > Thanks, I can really use the help. > > > > Daniel Elmore > > > > ---------------------------------------------------------- > > To post, send email to [email protected] > > To unsubscribe: > > http://www.dfwcfug.org/form_MemberUnsubscribe.cfm > > To subscribe: > > http://www.dfwcfug.org/form_MemberRegistration.cfm > > > > > > -- > Matt Woodward > [EMAIL PROTECTED] > http://www.mattwoodward.com > ---------------------------------------------------------- > To post, send email to [email protected] > To unsubscribe: > http://www.dfwcfug.org/form_MemberUnsubscribe.cfm > To subscribe: > http://www.dfwcfug.org/form_MemberRegistration.cfm > > ---------------------------------------------------------- > To post, send email to [email protected] > To unsubscribe: > http://www.dfwcfug.org/form_MemberUnsubscribe.cfm > To subscribe: > http://www.dfwcfug.org/form_MemberRegistration.cfm > > -- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com ---------------------------------------------------------- To post, send email to [email protected] To unsubscribe: http://www.dfwcfug.org/form_MemberUnsubscribe.cfm To subscribe: http://www.dfwcfug.org/form_MemberRegistration.cfm
