this is just a guess, but my feeling is the FluencyModel can actually be a very ...
this is just a guess, but my feeling is the FluencyModel can actually be a very small class, but with many helper classes all in one separate package. all a model really needs to do is capture the widget graph itself. it's all the ancillary information (like properties) that really bloat it.
i'm also guessing that FluencyEditorFrame may be a more complicated class to refactor, but i also have good hopes for it. typically these things 'just grow'. initially they're kinda small and clear as the programmer thinks 'oh, i need a frame here and a dialog there, and now some listeners etc.' but then it just bloats and bloats as that scheme turns out to be way to naive to deal with the necessary complexity of real GUIs---insets, layout managers, hit detection, focus, containment maangement, variant behavior because of OS implementation differences, etc.
Comments (1)
Apr 09, 2008
whoknows says:
this is just a guess, but my feeling is the FluencyModel can actually be a very ...this is just a guess, but my feeling is the FluencyModel can actually be a very small class, but with many helper classes all in one separate package. all a model really needs to do is capture the widget graph itself. it's all the ancillary information (like properties) that really bloat it.
i'm also guessing that FluencyEditorFrame may be a more complicated class to refactor, but i also have good hopes for it. typically these things 'just grow'. initially they're kinda small and clear as the programmer thinks 'oh, i need a frame here and a dialog there, and now some listeners etc.' but then it just bloats and bloats as that scheme turns out to be way to naive to deal with the necessary complexity of real GUIs---insets, layout managers, hit detection, focus, containment maangement, variant behavior because of OS implementation differences, etc.
-gjer