FreeMind refactoring plan

From FreeMind
Revision as of 20:32, 19 April 2008 by DimitriPolivaev (talk | contribs)
Jump to navigationJump to search

I propose following refactoring steps in order to improve freemind's architecture and design
DimitriPolivaev

Keywords Problem Measure
Property packages Over sized Model and controller packages Split model and controller in multiple classes responsible for different node and map properties (node text, edges, clouds, icons etc). Put thess classes in different packages. Provide facade classes for the packages. Let classes hosting the actions be specified in mindmap_menus.xml
Menu builder Lack of menu building component. The job is done by different controller classes which makes the menu difficult to extend. Introducing of menu builder (Design Pattern “Builder”) which can be accessed from all interested components during their initialization.
Undo handling Using jibx for XML serialisation of actions requires extending of the one xml document “freemind.xsd” for generation of marshallers and unmarshallers. Plug-ins can not add their own properties to maps and nodes without extending this file if they want to define their own actions.

Separation of action beans generated from this file from action code makes the code difficult to maintain and to understand.

Use of XStream library instead of jibx for XML – Serialisation.


Move action data into actor classes and let XStream do the rest.

Application classes Application initialization and building of application frame including tabbed panewith the map tabs, , scroll pane, split pane and so one is implemented in one class FreeMind which also extends JFrame. Move application initialization logic and tab management into new classes.
OSGI Very complex extension mechanism (Hooks) with long class inheritance hierarchies. Use extension objects pattern for model and controller. When model and controller should not depend on the property packages. Replace current Hooks by OSGI plug-ins directly extending controller and model classes via Extension Object pattern.
Preferences pane builder Almost elements of preference dialog set up in a single place. Introducing of property editor builder (Design Pattern “Builder”). The same bilder can also be used for building formatting dialogs.