Yeah, getRoles() would create the role objects on the first call to
it, and then on subsequent calls, return the existing instances:
function getRoles() {
if (NOT structKeyExists(variables.my, "roleArray"))
loadRoleArray();
return variables.my.roleArray;
}
function loadRoleArray() {
CFLOCK NAME="#variables.my.uuid#.loadRoleArray"
if (NOT structKeyExists(variables.my, "roleArray")) {
// build variables.my.roleArray
}
/CFLOCK
}
cheers,
barneyb
On 8/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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]
>
>
>
--
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]
