I would also think you could check to see how many objects are in the role. If there are no objects... instantiate, else use existing object. Interested to hear what the popular pattern methods are on something like this... but it seems that unless it's an always called has object, then this would be the better design.
John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 22, 2005 2:21 PM To: [email protected] Subject: RE: [CFCDev] composition Lazy Loading. Have not heard that term before. So, perhaps in the example given, I could have a GetRoles() method of the person class that would return an array of instantiated role objects? This way I can get the roles as needed and save the upfront initialization time. Tom -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Monday, August 22, 2005 1:17 PM To: [email protected] Subject: Re: [CFCDev] composition Lazy loading is generally the way to go. I.e. when the role is needed, load it then, not when you create the person. In most cases, that works well, but you sometimes run into issues with transaction boundaries that force you to do up-front loading of internal instances. cheers, barneyb On 8/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Does it make sense to instantiate "foreign" CFCs when you instantiate your > main CFC? For instance, let's say I have a person instance and that person > has specific roles (a person is composed of roles, or "has-a" role). Does > it make sense to instantiate each role as an instance when I instantiate the > person? Perhaps an array of instantiated role objects? Seems like this is > overkill to happen each time you instantiate the main CFC (person). What's > the best practice here? > > Tom -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
