"Jim Morcombe" <[EMAIL PROTECTED]> wrote
> In it, Dakota recomends placing the entire application within a
> class.
> Why is this so? Surely in many cases you end up with a constructor
> for the class that is cumbersome and complex?
This is a very common OOP technique, especially in languages which
only support objects, like Java and SmallTalk. Indeed some OOP purists
would claim that its the only way to wsrite a pure OOP application.
The constructor should not be very complex in a well constructed OOP
program because it should only consist of processing any startup args
and then the creation of a few top level objects. And without a top
level class this would be done in some kind of initialisation function
anyhow. Usually the App class will have a Run method or similar
so that the module code looks like:
#### module here
class MyApp:
def __init__(...)
# process sys.argv
# create top level classes as attributes
def run(...)
# control logic for application
if __name__ == '__main__':
MyApp().run()
###############
The advantage is that it is relatively easy to create variations of
the
program by subclassing the application. The disadvantage is that you
don't often sub class applications in practice! (At least in my
experience)
> Is this a recomended Python programming technique?
I've never seen it recommended for Python in general, but it is quite
common, particularly in GUI apps. Indeed it is the recommend way for
wxPython where you must create an Application class or use the built
in SimpleApp class,
HTH,
--
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
