Your child elements should be initialized in the constructor (init() method, for CFCs), so they should already exist by the time setMemento is called. If you have a class where a given instance varible may not be set (rare, but possible), just add a check in setMemento, and initialize the object first, if necessary. Probably want to put the actual initialization into a separate private method, as it's going to be used at least two places, and you don't want to have to update two places if it later changes.
barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Justin Balog > Sent: Wednesday, December 10, 2003 1:53 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] memento and composition > > Real qucick follow up on this, I know I am a little bit late, but just > getting to trying it out. If in the parent setInstanceMemento(), I am > calling child.setInstanceMemento(), where is child getting created? > > Thanks again, > > Justin > -----Original Message----- > From: Paul Kenney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 26, 2003 3:19 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] memento and composition > > > Justin, > > I would say that you also implement get/setMemento() in the > objects that > make up the composition. When getMemento() is called for your Person > object, that Person object calls getMemento() for each of its > member objects > (Address, Name, etc.) and places the result in its own > returned Memento > object/struct. This way, the owning object is responsible > for it member > objects. Just to clarify, I put example psuedocode below. > > > class Person > { > Name fName; > Address fAddress; > > ... > > struct getMemento() > { > result = StructNew(); > result.name = fName.getMemento(); > result.address = fAddress.getMemento(); > return result; > } > > void setMemento(struct data) > { > fName.setMemento(data.name); > fAddress.setMemento(data.address); > } > } > > class Name > { > string fFirstName; > string fLastName; > > ... > > struct getMemento() > { > result = StructNew(); > result.firstname = fFirstName; > result.lastname = fLastName; > return result; > } > > void setMemento(struct data) > { > fFirstName = data.firstname; > fLastName = data.lastname; > } > } > > class Address > { > string fStreet; > string fCity; > string fState; > > ... > > struct getMemento() > { > result = StructNew(); > result.street = fStreet; > result.city = fCity; > result.state = fState; > return result; > } > > void setMemento(struct data) > { > fStreet = data.street; > fCity = data.city; > fState = data.state; > } > } > > > > Paul Kenney > WebMaster, CorporateWarriors.com > 916-630-4545 > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Justin Balog > Sent: Wednesday, November 26, 2003 1:21 PM > To: '[EMAIL PROTECTED]' > Subject: [CFCDev] memento and composition > > > > Howdy, > > I am running into a design question. I have been doing a lot > of thinking > about this, and haven't come to any conclusive answer. I > always have issues > with composition because its seems like it adds quite a bit > of complexity to > applications, surely it helps with Code reuse, but it goes > against my (Keep > It Simple) style of application building. You start adding > complexities, > and things become brittle. My question is, lets say I have a > person.cfc > whose composed of normal instance vars and an address.cfc > (wow I have really > beat this example to death). Looks good to me. However, I > also took Sean's > get/setMemento() concept from his mach-ii sample app (Sean's > stuff is good, > and I hate dragging him into my convoluted questions. I just > feel obligated > to cite my sources). If your object is Flat, meaning its not > composed of > other objects, memento is really slick, clean and tidy. Just > set, or get > the instance vars. But once you introduce composition, its gets a bit > uglier. Can anyone help ease my fears about composition, possibly an > example of how folks have used the memento concept with > composition. I am > guessing its much like Barney suggested to me a while back > when I asked > about serialization. To me it seems like a tradeoff of > flat stability, or > complex reusability. Hmm.....any thoughts? > > Thanks much, > > Justin > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.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 word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.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' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
