[Tutor] design question

[Albert-Jan Roskam]

Hi Jan,

Here's a screendump of my program: http://nl.tinypic.com/r/2qtlojc/7 . This 
might make my description a little bit clearer. The beautiful sunset will in 
reality be a dull, handwritten form. ;-)

Regarding the iterator pattern, I was referring to this: 
http://www.suttoncourtenay.org.uk/duncan/accu/pythonpatterns.html#iterators-and-generators

Inside my program I have to keep a list of all the image files that are 
scheduled for data entry. The main purpose is to be able to read in the image 
files one by one. Another one of the purposes of this list is to show some 
information on the title bar. Currently, my program only has a 'next' button and 
the fact that implementing a 'previous' button is causing problems suggests to 
me that I have to look for a more fundamentally better solution.

 Cheers!!
Albert-Jan


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All right, but apart from the sanitation, the medicine, education, wine, public 
order, irrigation, roads, a fresh water system, and public health, what have the 
Romans ever done for us?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




________________________________
From: Knacktus <knacktus at googlemail.com>
To: tutor at python.org
Sent: Fri, September 10, 2010 3:38:13 PM
Subject: Re: [Tutor] design question

Am 10.09.2010 11:23, schrieb Albert-Jan Roskam:
> Hi,
> 
> I've made a small data entry program where a picture of a hand-written,
> scanned form is shown next to several text entries. The design has been
> largely 'bottom up', although of course I started with a rough sketch. I
> started with the following classes: Menu (responsible for the widget
> creation), Autocomplete (a subclass of the tkinter text entry widget
> which I've found on the internet, I wanted to keep this intact), Convert
> (responsible for the conversion/cropping of the images, which is
> somewhat tedious) and Events (here's the pain spot: this has become a
> mixed bag). Originally, the Events class was supposed to contain all the
> commands behind the widgets, but it has slowly gotten more
> responsibilities. Notably, all methods that deal with reading/writing
> the data also live here. The program is about 500 lines of code now,
> including blanks.
It's difficult to judge from the outside. It sounds to me like a good idea to 
create separate classes or modules for reading and writing.
> 
> I'd like to rewrite to entire program so that (1) all classes have just
> one responsibility (2) classes connect to as little other classes (so it
> becomes easy to e.g. change to another widget set). I'd love to hear
> some thoughts or advice on the new design from you (I hope my
> description wasn't too short). Is there a specific design pattern that
> could be used?
> 
> One specific, additional question: the program has a title bar that
> shows something like "processing file X (1 of 3; 33%)". My colleague
> suggested to use the Iterator pattern (gang of four) for this. Is this
> (a) overkill (b) a simple opportunity to apply this pattern?
For what exactly do you want to use the pattern?
The iterator pattern is easy to implement in Python. And the usage of iterators 
is even more easy (you can use them in loops without calling the next() method 
explicitly). Lists among others are iterator types. You can create your own with 
generator functions or of course implement the iterator-protocol. See here:

http://docs.python.org/library/stdtypes.html#iterator-types

Generally iterator types and generators are great features of Python. For a more 
concrete advice you'd need to explain a bit further what you need to do.

HTH

Jan
_______________________________________________
Tutor maillist  -  Tutor at python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20100910/a767555b/attachment-0001.html>