Great! thanks. Although what I asked is somewhat abstract and the answers are also somewhat abstract. I think I've already learned a lot.
How do you tell if an OO design is bad? :) Thank you everyone! Henry Ho On Feb 20, 1:48 pm, Dan Wilson <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
