Henry, Both ways could be valid depending on the architecture and design of the rest of the application, requirements and use cases. Since you are somewhat tight lipped about the real use cases and purpose of the system, you are probably the only person with enough information to make an accurate judgment.
You know, when I started learning to write applications in an Object Oriented manner, I asked a lot of abstract questions and people gave me abstract answers in return that didn't do much to stop my poor head from spinning around in an effort to get my arms around the design implications and tradeoffs from one approach over another. Frankly, the only way I learned to write decent OO code was by writing a whole lot of crappy code. ( sorry previous and unnamed employer). So rather than asking questions about every intimate detail of your application, maybe you would benefit more from getting something working and then going back to refactor out the crap after that. Seriously. There is no magic spell, recipe or prescription for 'correct' OO code. You can't learn golf from watching the golf channel and asking golf questions. You gotta actually swing the club. DW On Fri, Feb 20, 2009 at 4:35 PM, Henry Ho <[email protected]> wrote: > > The child (City / Page) will very likely depend on its the parent > (Country / Site) to carry out some of its behaviours (by completing > the design against list of use cases). > > So it is logical to have the child carries either reference to parent, > or reference to proxyParent, or just parentID, to represent the > relationship in the OO level. > > And with such representation of the relationship, the DAO of chlid > (City / Page) can then save itself properly. > > Am I on the right path of thinking? > > Thank you, > Henry Ho > > > > On Feb 20, 1:15 pm, Matt Williams <[email protected]> wrote: > > The answer here is: "It Depends." And as Justin said, use your best > > judgment. > > > > There is nothing wrong with just storing the ID of the parent > > Country / Site. Most likely it is in fact a foreign key in the child > > table. > > > > On the other hand, putting the parent Country / Site object in there > > may be necessary. A City may need to reference a property of the > > Country such as what hemisphere the country is in or a federal law. > > Likewise a Page may need to reference Site-wide variables such as the > > secure URL or whatever. > > > > Another way to look at it would be that if the child object is a > > transient and does not need anything related to the parent, then don't > > bother putting it in there. But if both are singletons, there is no > > significant additional overhead to putting a reference to the parent > > in the child, so go for it. > > > > Again it depends on your use case and use your best judgment. The > > worst case scenario for doing that is some refactoring, which can be a > > good exercise anyway. > > > > Matt Williams > > > > On Feb 20, 4:01 pm, Henry Ho <[email protected]> wrote: > > > > > Let me try to explain with another example. > > > > > A Country has many City. > > > > > So.. let's say I want to create a new City. In order to be a valid > > > city, it has to belong to a Country. However, if the City has no > > > behaviour that requires Country, does it make sense to have City carry > > > a reference to Country? > > > > > The system, (through use of singleton) must be able to answer which > > > city belongs to which country, but City object itself does not. > > > > > Thanks, > > > Henry Ho > > > -- "Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew." Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
