On Tue, Feb 10, 2009 at 9:07 PM, Henry <[email protected]> wrote: > > I have a few questions... > > Please assume that I'm not using and I can't use any ORM like > Transfer. > > If your answer is "It depends", please specify what it depends on. :) > > > 1. Should the parent object store the id of the child object, or a > reference to the actual child object? > > Transfer needs us to always use reference to the child object, that's > why we can't say parent.setChildId(1). Instead, we must use > parent.setChild(transfer.get("child",1)), which I don't like. > > However, if I only store the child ID, then I must force the user of > the parent object to always save the child object first, which is hard > to unit-test, which I don't like either.
It depends on your use case. If there are a large number of composed objects, storing the ID or some kind of proxy object (as Transfer will let you do) makes sense. But ideally you should store a reference to the real object. > > > > 2. If the child object is shared by more than 1 parent, should the > parent all reference to the same instance of the child object? If so, > how? > > Possible implementation: > - Storing a struct of child objects by ID in Application scope? That > sounds bizarre and wrong > - Factory pattern with cache layer?? > > If not, then the updated child might be overwritten by an old child by > another parent object. e.g. > Parent A @ init'ed, has copy of Child1, Child1.name = "ONE" > Parent B @ init'ed, has another copy of Child1, Child1.name = "ONE" > Parent A update Child1's name to TWO > Parent A save (Child1 saved, Child1.name == TWO) > Parent B save (Child1 saved, Child1.name == ONE) > Yes, there should only be one instance of the same concrete object at a time, or you'll run into a storm of synchronization issues. Which means some central cache is required to ensure duplicate objects are not created. > 3. Should the parent act as facade and all operation goes through the > parent, when the child object is used only by the parent? Let say the > parent object is a Room object. The Room object has a Door object. > The Door has open() and close() method. If I need to close the door > of the room, what is the better? > > room.getDoor().close() // no facade > room.closeDoor() // with room acts as facade > > I like the 2nd one more, because the user of Room object does not need > to know about the Door object, but then wouldn't the Room object end > up having a lot of methods even though they're only one-liner? > The Law of Demeter pushes the second option. However, you must be cautious not to fall into the "Middle Man" antipattern where an object becomes primarily a series of methods that simply forward to other objects. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
