[Tutor] preliminary app design question

[Kent Johnson]

Richard Querin wrote:
>  
> On 4/5/06, *Alan Gauld* <alan.gauld at freenet.co.uk 
> <mailto:alan.gauld at freenet.co.uk>> wrote:
> 
>     Sounds like creating each app as a class which can be instantiated on
>     demand by the master application would be a possible design option.
> 
> I guess writing the master program (or some simplified version of it) 
> would be required from the start in order to make launching the separate 
> design programs possible (for testing, debugging etc..).

Not really. You just have to write the separate design programs in a way 
that they can be integrated with a larger whole. This means, write the 
functional part of the program with an API that can be easily be invoked 
to make it do the work. The API can be class-based, as Alan suggests, or 
standalone functions, whichever is simpler. Then for a standalone 
program you can write a main() function that works from the command line 
or a GUI. For your master program you can invoke the API from whatever 
framework you come up with.
> 
>     The class approach coupled to a config XML file would do this.
>     Define a file that looks something like
> 
<snip suggested XML config file>
> 
>     Then you can read that and use it to construct a menu or set of buttons
>     or toolbar or whatever.

XML is obviously a bit controversial, you have several contrasting 
opinions already. I have successfully used XML and a DOM data model in 
several applications and I would do it again. For configuration I would 
look at something simpler, possibly a Python module that configures 
other modules or maybe a plug-in mechanism. Or possibly you just write 
your master program to call the subprograms as libraries without any 
dynamic configuration at all - just hard-code it.

I should note that my experience with XML data models is from using the 
excellent dom4j library with Jython. I haven't found any Python XML 
packages available for Windows that have the same combination of power 
and ease-of-use as dom4j.

> I think my first task will likely be settling on what I need each 
> component of the system to do and how they will interact. It's becoming 
> more complex the more I discuss it.. ;)

I would say your first task is to write some code that does something 
useful. Then write some more and make them work together. Repeat as 
necessary. Don't try to figure it all out up front.
> 
>      > Obviously this won't happen right away, I would likely develop each
>      > small design app as a standalone and then when I've got 3 or 4 done
>      > I would tie them together with the project app.

When you have two standalone apps then you can reasonably think about 
how to tie them together. Before then too soon - you don't know what the 
standalone apps are going to look like until you make them. After you 
have three is getting to be too late - when you integrate the apps you 
will discover things you want to change about them to make the 
integration easier, and that will inform the way you create the next app.

Don't leave out the unit tests - when you want to change your apps for 
integration (or any other reason) the unit tests will give you 
confidence that you haven't broken anything. Also writing the apps to be 
testable will help make them usable from another app.

Kent