Boy, Condoning sounds like such a harsh word. ;O)
I'm suggesting that it depends. Personally, if I had more than 2 dependant objects being used, or if I felt like my object might end up utilizing more than 2 dependant objects when all is said and done then yeah, I would just pass in the factory.
An example of an object I have created before which takes in a factory. I did a project for a state government that they use to track a variety of educational information with. One of my components is a student enrollment which contains stuff about the student and the class and how the two relate to one another.
The student enrollment init method takes in a reference to my DAOFactory which gives me access to the studentDAO, the classDAO, addressDAO, assessmentDAO, and a few other things that all apply directly to that students enrollment. The studentEnrollment object is pretty tricky because there is so much going on and depending on how the students enrollment was being interacted with by the user via the UI certain subsets of the students enrollment might be modified at one time or another. For instance a teacher might modify that students achievments within the class, or their test scores, or their contact information.
The students are pretty special in that they are adult students so the have the opportunity to hide the fact that they are enrolled in other classes from their teacher.. so alot of stuff that would normally just be consitent to the student across classes regardless isn't in this system. Such as their SSN - they have the perogative to withhold it from every teacher, but they might give it to some (this happens quite a bit).
Sorry, i'm kind of wandering off course with this answer. But basically it depends on your circumstances. I definitely don't think it is verboten to pass a factory into an object that is instantiated by the factory.
However, with either process (passing in a factory or each individual component) I would add an accessor method to my object that lets me get the dependant object without referencing the factory or the variables.instance.object instance directly; that way if I change my mind later I don't have to change all my internally referencing code.
Bill
----------------------------------------------------------So Bill, are you condoning only passing in the Factory to init() and using it to create the dependent objects – rather than pre-creating the objects in the factory and passing THEM in to init()?
Baz
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Rawlinson
Sent: Wednesday, November 02, 2005 1:19 PM
To: [email protected]
Subject: Re: [CFCDev] Factory Pattern
Also you had discussed, at one point, passing the factory into the object during init - this way if the number of dependant objects changed in the future you wouldn't have to muck with how the primary object was instantiated since the factory would already have references to those dependant objects.
BillOn 11/2/05, Patrick McElhaney <[EMAIL PROTECTED]> wrote:
On 11/2/05, Scratch <[EMAIL PROTECTED]> wrote:
>
> On a related note, remind me again why it's better to create the dependent
> objects in the Factory rather than just creating them in the object's
> init():
The init() method is a convention used to simulate constructors. In
other OO languages, you create an instance of an object by calling its
constructor. They're not two distinct steps that can be done at
different points.
Patrick
--
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]
If you want Gmail - just ask. ----------------------------------------------------------
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]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
