Hi Dimitry, your mail is far to abstract for me. You only write: "it is everything too complex." without any concrete references. And if you find this references, I would propose that you spend your time better in documenting them or - at least - to write an email to me with the request for documentation or explanation.
Regards, Chris Dimitry Polivaev schrieb: > Hello, > > last days I have spent many time analyzing current state of the program > design. And I have run into troubles: IMHO the complexity of the program > which can be measured on amount of different interfaces, classes and > dependencies between them, is significantly bigger than required by the > features we have. The purposes of many classes and the patterns they > follow are neither documented nor self evident, the class and methods > names are not really helpful either. > > Because simplicity and clarity of the program design is very important > for both its long life and my satisfaction as a developer, I am not very > happy about it. > > I see the following ways to deal with the problem: > > 1. Because the only two persons significantly contributed to the program > in the last years, we could try to exchange and complete our knowledge. > > We could provide a javadoc documentation explaining the intention of the > relevant classes and packages. We could also use any kind of synchronous > communication with the purpose of understanding the things before trying > to change them. We could use chat, skype or phone, but I could also > personally come to Berlin for one or two sessions. This way we could > design the changes together. > > 2. Alternatively I could develop a new design by myself. The new design > would have a relatively small kernel and further mutually independent > packages depending only on this small kernel. > > The new design would extensively use the Extension Object pattern > proposed by Erich Gamma and used in Eclipse. The pattern is described in > his book "Contributing to eclipse", it is also explained in > > http://www-st.inf.tu-dresden.de/Lehre/WS04-05/dpf/slides/9-framework-extensibility.pdf > > (Personally I have read the book, the pdf is just a link returned by > google). > > This pattern makes possible attaching of the any extension objects to > some object which does not depend on them by itself. Using this pattern > we could attach new actions to the controller or new model elements to > maps or nodes without changing their own code. > > Such design would make no difference between managing of the freemind > "native" actions and model elements and of the elements coming from a > plug-in. (NodeView is already able to display added elements, it results > >from refactoring I did 2007). The current plug-in framework (which IMHO > is very difficult to use and to understand) could be replaced by more > transparent and light-weight solution. But if I had to work alone, I > would be not able to consider Chris's ideas and wishes. > > Dear Chris, that's why I would like to ask you to write your wishes > about how to organize our work and communication here if this list. > > Best regards, Dimitry > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Freemind-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
