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 <[email protected]> To: [email protected] 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 - [email protected] To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
_______________________________________________ Tutor maillist - [email protected] To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
