I've been looking through the JUMP code in various places and it looks like there are a lot of cases where custom sub classes are created just to change a few parameters on a class (e.g. com.vividsolutions.jump.workbench.ui.renderer.style.ArrowLineStringEndpointStyle). In this class it defines a number of sub classes for each different style, all that changes in some of these classes is the name, start indicator, image, min angle, min length and if it's filled.
By creating sub classes for each of these you add extra overhead to the application as it needs to have the Class definition loaded in the PermGen space of the application. By contrast if you had a factory based approach that would create instances of the class you could have a couple of factories and a few implementations for the different parameterizations possible then the overhead you have is a few bytes for the configuration paramters rather than the KBs for the class definitions. I'm not suggesting that we go and wholesale change the existing code but it's something we should be aware of when implementing new features. The areas where we can create generic components include. - Event handling - Object edit panels, tables Paul ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
