designing question

[Andy Robinson]

pserrand <bucodi at worldnet.fr> wrote:

>> > 2. The application will have abouth 50 different inputscreens wich
>> > acces all to different tables. I will create a class for every
>> > window wich inheret from a general 'input-screen'-class. I wonder if
>> > a should place the db-access code (insert-update-delete) in every
>> > specific window or if i should  create a big db class wich has all
>> > possible db-acces in it ?
>>
>> Completely philosophical question. For flexibility, I favor the GUI
>> making no assumptions about how the data is stored. I would have the
>> GUI making calls like "app.addthingie(thingie)", where the app has an
>> "abstract" UI.
>
>I'm surprised that this is just a philosophical question :) I tought
>there would be some
>practical reasons to do it one or another way (p.e. maintenance of the
>application)
>The reason i posted this question is that i have very little experience
>with OOP. (actually i learned it with python <wink>) So i'm looking for
>some experience here
>
With 50 screens, it is going to be complex.  I'd suggest first
modelling the 'objects' your program deals with.  Thus, if it is an
invoicing program, you make objects which represent the invoices,
customers, payments etc in as natural a way as you can.    Build
Python classes and play with them at the interactive prompt; you can
do this faster in Python than in anything.   If the object model is
right, then building a natural GUI on top of it and a database behind
it are fairly straightforward tasks; and the program is easy to
extend.


Good luck,

Andy