Hi Chris, I have not got time for detailed answer until now, so let me write a short one so that you do not have an impression being forgotten.
> But a pair that belongs always together is a MapModel and a > ModeController. (This answers the last mail of Dimitry). If we have > only one ModeController (per mode or globally), the controller is not > aware of the model it controls. He is stateless. But then, he isn't > able to control the model, as there are states in the controllers > (I'm thinking of different states like: node, free node or picture > selected, menu states, and if I would have more time, I would think > of more). IMHO, there is no advantage (except saving some 200Bytes > for each instance of a controller) having only one, because you have > that every action of a controller has to ask: to which map do I > belong currently? And you have more problems to have parallel > controller actions in the background of several nodes currently not > displayed in the active map. Well, the mail is long enough now, I > think. I do not propose to use the singleton pattern any more, but I still think that creating of individual action objects, menu structures and plug-ins for each single map is not always necessary. Things like Undo-History should be created for each single map. But even if we have different menu states I would not create every menu item of every state again and again. I would use a strategy pattern with a limited number of variants created once. And I think that the mode controllers already implement the strategy patterns, and in this case different states you write about are further modes we could define. And the most important thing for me is communication do that the design become more clear and evident. So I shall try to work in this direction and create some diagrams when I have time for it. > all kinds of global variables" is exactly the problem. Moreover, > you've noticed, that it is very difficult to use the NodeView or > MapView for example to display some example nodes in the format menu > (an idea, which should be realised, IMHO). One reason for this is, > that nearly every class of FreeMind needs all other classes to work - > called "tight coupling", AFAIK. > > But the best code originates IMHO from lose couplings - a class needs > only itself and a hand ful of helpers that register at instanciation > time or later. These helpers are decoupled by interfaces and their > implementations. Only with this "ansatz", the software can be tested > on module level and parts of the software can be reused. > > I'm going to try to realize more of this decouplings in the future > (I've already started, if you look at some of the new dialogs > (perhaps the script editor), which can be tested stand-alone). It would be very helpful for synchronizing our efforts if you could tell us more about the changes or concepts you are realizing. Regards, Dimitry ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
