software design question

[Lothar Scholz]

Uwe Mayer <merkosh at hadiko.de> wrote in message news:<c03rii$c2t$1 at news.rz.uni-karlsruhe.de>...
> Pierre Rouleau wrote:
> >> So the question is rather: how to make a better design?
> > 
> > Why not look at the GUI as a "presentation layer" that provides access
> > to the program functionality, like file I/O, help access, etc.  Then the
> > file I/O, help, (etc...) can be written without any knowledge to the GUI
> > (and therefore testable from a python shell or a testing script) and the
> > Gui code just call the File I/O, help functions or members.  If you need
> >   callbacks, then provide callbacks.   This way you would decouple the
> > GUI from the system functionality.  Only GUI code would import the other
> > modules.  The File I/O, help (etc...) would not know anything about the
> > GUI implementation requirements.
> 
> I've already got separate modules for non-GUI related functionalities, i.e.
> accessing record based file formats, etc. These are imported by the module
> that currently covers "Open", "Save", "Save As", "Properties", "New" (in
> the File menu).
> This alone spans 442 lines (including comments and empty lines), containing
> only dialog interaction and calls to the previously mentioned file-module. 
> 
> Is 500 lines a good count to start splitting up the code?

No !
My modules are normally between 1000-3000 lines. Having to much files
(worst case scenario is PHP) is just another form of spaghetti code.
With so small files you should focus on the task that needs to be done
and only if you really do two different things in one module you
should decide to split it. Maybe a merge would help you more then
splitting.