Is there an obvious way to do this in python?

H J van Rooyen mail at microcorp.co.za
Fri Aug 4 06:26:47 EDT 2006


 "Dennis Lee Bieber" <wlfraed at ix.netcom.com> wrote:


| On Thu, 3 Aug 2006 16:50:15 +0200, "H J van Rooyen"
| <mail at microcorp.co.za> 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







More information about the Python-list mailing list