"Dennis Lee Bieber" <[EMAIL PROTECTED]> wrote:
| On Thu, 3 Aug 2006 16:50:15 +0200, "H J van Rooyen" | <[EMAIL PROTECTED]> declaimed the following in comp.lang.python: | > Now part of the reason I would like to go the transaction type route instead of | > the "per user" route is robustness and maintainability, and the ability it | > would give me to introduce new transaction types easily - as I see it if say an | > invoice's GUI code is stable I would never have to touch it again even if I | > combine it with anything else, as it would have been designed from the start to | > combine with others of it's own ilk, under a kind of communications controller | > that is standard... | > | Uhm... You've just described the "raison d'etre" of Object Oriented | design/programming. Oh No! - curses! It has slipped in under the radar! - I have always thought that the reason for going the OO route is to obfuscate the code so that mere mortals could never understand it... | | Each of your "transactions" (tasks/jobs/functions) would be a single | "class" (this does not mean they may not incorporate other classes as | part of them). Ideally, each class should be independent of the others | except for a defined API. The "invoice" would be one "class" (actually, | you may have a class for "invoice data" -- this being the information | passing between the client and the server; and a class for "invoice | presentation" -- the GUI. Plugging in another task should only involve | the main client (new menu entry) with maybe an "import new_task" so | picking the menu entry instantiates new_task. | -- Yes got it, thanks- Hendrik -- http://mail.python.org/mailman/listinfo/python-list
