To me it sounds like what you need is more of a Model/View separation. You've got the Graph data itself, and then various UIs that are used to display the data. I would try to separate the UI related code and the raw data for the Graph (I did something very similar to this for a whiteboard application I wrote).
If the various UIs need to have extra data for the model, then you might want to have the nodes contain a map of properties, so different UIs that need different properties in the nodes can add them as they need them. -Andy On 12/18/06, Ron Wheeler <[EMAIL PROTECTED]> wrote:
I hate to encourage sloppy thinking but sometimes you just have to make some decisions and start. Always look for methods that are getting too complicated. If it is more that 10 lines of code excluding trivial repititions, it is a candidate for some sort of investigation. After 25 lines of code real code, you need to have a reason for its continued existence, and after 50 lines of code you need a note from your mother explaining why you can not break this down into smaller chunks with some subsidiary classes or helper methods. I could be a bit too strict but this will keep your code and class structure maintainable. Ron hank williams wrote: >> >> I sometimes find that every time I read a book on software architecture, >> it messes me up and I design worse programs. > > > This is my fundamental concern with being too attached to the "right" > design pattern. > > I suggest you write your program in the way that makes most sense to > *you*. > The goal of design patterns is to write code that *you* can > understand. It > is of course possible that you will come to believe at some point that > you > have made some design or architectural mistake. In fact, consider it a > strong likelihood. I believe one of the most important lessons you can > learn > is to become comfortable refactoring your code. And do it often. Your > will > have a good design not if you make perfect initial decisions, but if > you are > flexible, and when you see that you could do something better, you do it. > Don't be afraid to make a wrong first step. But more importantly, be > fully > prepared to fix a wrong first step. > > Regards, > Hank > _______________________________________________ > [email protected] > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > > _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
_______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
