Linus said: > [the GUI class] is an attempt to break up the > ProjectBrowser class by moving some responsibilities out of it.
It sounds like we agree that the ProjectBrowser has turned into a tar baby. It seems to have become the dumping ground for every piece of global state that lacks a home of its own. The comment that you identified was part of a larger attempt to break the strong coupling between the ProjectBrowser and other classes. The comment was actually obsolete even before it was committed because I'd already decided that it would be better for the LRU menu to listen directly for notification of file save events (and have the file saver post those notifications). I spent several hours teasing apart the ball of string that is ProjectBrowser since Classcyle had identified it as the "best fragmenter" for the large cycle of 758 classes. Because ProjectBrowser acts in so many different roles, my first task was to separate out the methods and data for the various roles into separate classes so that I had a cluster of interrelated classes that I could use to trace what depended on what. Because ProjectBrowser is basically the 2nd highest layer (after org.argouml.application.Main) any reference to it from a lower level component is likely to introduce large dependency cycles. After splitting things up and breaking a few of the dependencies I was able to reduce the size of the largest cycle from 758 classes to 229 classes with ProjectBrowser off in its own little cycle of 21 classes. Some of the issues that I identified with ProjectBrowser as part of this investigation include: - lots of ProjectBrowser.getInstance() calls used solely as parent for popup dialog box. We can probably use null or figure out the main application window using Swing calls for most (all?) of these. - there are several references getStatusBar().showStatus which should probably just post status events that the statusBar can listen for - There are a number of Actions managed as singletons (undo/redo, save project, remove from diagram). I didn't look into which ones really need to be singletons, but I split them all off into a separate class just to separate them from ProjectBrowser for investigative purposes. - There's a ton of code specifically for Loading/Saving projects which I split out. - jumpToDiagramShowing() is only used one place (UMLToDoItem) so I moved it there temporarily, but we should probably use the TargetManager or a similar mechanism - setToDoItem() - similar to above. The details pane should probably listen for target changes. - getTab() - only used in ToDo management - use event instead Most of the (private) changes so far have been just to enable the investigation rather than production ready code, but the one small change that I thought was non-controversial (to break the large cyclic dependency in the GUI class introduced by http://argouml.tigris.org/servlets/ReadMsg?list=cvs&msgNo=11447) was immediately rejected by Linus, so I figured I should stop, summarize the results of the investigation so far and figure out what to do next. I'd really like to see something done about this big ball of spaqhetti and was willing to do the work, but now I'm unsure what the next step should be. Should I let someone else do this work? Should I just drop it? Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
