ANN: Thinking in Tkinter

[GerritM]

"Stephen Ferg" <steve at ferg.org> schreef in bericht
news:b16e4ef7.0209130432.7fb3ee61 at posting.google.com...
> > I can't really say WHY using a class structure is desirable.
>
> It is coming back to me now.
>
> As I was working on easygui.py (http://www.ferg.org/easygui/), I
> noticed two things. (1) I was using global variables a lot.  (2) I had
> several GUI "chunks" in one Python program, and when they were all at
> the same level, the code was really unstructured.  Very hard to
> understand.
>
> Granted, a lot of my confusion was simply newbie confusion.  But I
> thought that the next Tkinter development I did, I would see if
> structuring the GUI component into classes would help with these
> problems.  Even in the limited development I've been doing for
> "Thinking in Tkinter", it seems to me that: (1) being able to refer to
> "self." variables removes the need to make so many variables global.
> (2) Grouping the GUI material into classes really helps bring some
> structure to the program that it didn't have before.  I suspect that
> the importance of this (which may not be that obvious in small
> programs) will become overwhelmingly obvious in larger and more
> elaborate GUIs. One of my "to do" items is to test this hypothesis by
> re-writing easygui.py using a class structure.
>
> So right now, my hypothesis is that -- although Tkinter technology
> does not *require* you to structure your GUI as class -- doing so is
> probably desirable simply from the standpoint of making a large
> program more manageable.

I do recognize this evolution. In the beginning  a simple script is used and
global variables start to appear. My experience is that globals are always
suspect. So when the problem and solution is reasonably understood it is
time for refactoring, where structuring in classes frequently is the natural
pattern to use.

I would recommend to follow this logic in your stepwise introduction as
well. So start with very simple "scripts" which have globals, which are
structured in classes when the problem and solution grows and globals become
really dangerous.

Starting with classes up front is not always preferred, simply because you
don't have sufficient insight in problem and solution structure. The result
of too early classes is a lot of self induced additional
statements/structure, which only clobber up the understanding and require
more refactoring than the more pragmatic beginning with globals.

regards Gerrit
--
www.extra.research.philips.com/natlab/sysarch/