@Henry, there are many people that can help. They write great books on this subject of designing a Domain Model.
Buy books from (or Google) people like Robert C Martin (Uncle Bob), Martin Fowler, Kent Beck, read the Head First books on OO and patterns (2 books) , get into TDD as this will quickly guide you into a testable and better designed domain (because if it's hard to test there's something wrong) I am still struggling with the process of building a Domain Model and even code I wrote a few weeks back I'm seeing problems with and creating 'refactoring' tickets into Jira at work. As Sean Corfield keeps saying 'OO IS HARD' - all we can do is try things, make mistakes, read as much as we can, ask questions on lists like this and hopefully evolve. I enjoy your questions on this list. It makes me think and I'm maybe even *addicted* in a weird way to try and answer them as it helps me evolve too so please keep them coming :-) But maybe next time use things like Product, Order, OrderItem, Shipping etc or common things that in CF we're used to (CMS, User Management etc). Rooms and infinate Window delagates confuse me! I know your project is top secret but I'll guess something similar has been done before. If not then keep it secret and use common web app examples and more people will chip in their 2 cents Alan ________________________________ From: Henry Ho <[email protected]> To: [email protected] Sent: Wednesday, February 18, 2009 1:23:45 AM Subject: [CFCDEV] Re: OO question, how should I model this? Thank you Brain and everyone else for you patient. I should learn how to ask a question before I can ask the question. :) I wish there is someone like you at my work place, then I can just ask you directly with my class diagram. Regards, Henry Ho On Tue, Feb 17, 2009 at 5:13 PM, Brian Kotek <[email protected]> wrote: On Tue, Feb 17, 2009 at 6:53 PM, Henry <[email protected]> wrote: BookmarkManager cannot be Singleton because it has states (i.e. a collection of links, more specifically it shall be a Tree). Again, the completely arbitrary context you're throwing out here is making this very difficult, Henry. Why can't BookmarkManager be a singleton? I'm quite sure that in my copy of Firefox, if there is a BookmarkManager or some comparable object, there is only one instance of it. Why would it need more than one? Imagine there's a Browser table, and one row of it represents a Browser. There's a field calls bookmarks (since a browser has bookmarks), and it is a JSON representation of the collection of links. Stop, and don't mention database tables again. Going down that route is only going to make trying to offer advice even more difficult than it already is. "Browser shouldn't be the access point for BookmarkManager.", then who else can have references to BookmarkManger's that the view can ask for? I'll ask again: Why can't the view have a reference to the BookmarkManager directly? Where did you latch on to the idea that the view ONLY talks to this Browser object? By the way, what is this "View" even supposed to be? An OS native window? An AIR UI? Unless you can clearly state what it is you're trying to model, the context that it exists in, and the actual USE CASES that must be met, this thread is basically going to keep going around in circles. We've already hit 25 messages and don't understand what you actually want to know! If the question is "what number of delegation methods can I put into an object?", the answer is "the appropriate number". Yes, that's the actual answer. Because if you ask an abstract question, it results in an abstract answer. It might not be the answer you'd like, but I'm afraid it's the only valid answer without the details I asked for above. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
