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
