Hi all,
I'm working on my first object-based-from-the-ground-up project, and I have some queries.
http://www.rafb.net/paste/results/lDUmWS78.html
Here are my two classes here. For each different function, search, edit, view, etc. a different SQL operation will take place, and a different child window will be returned to the main window. Roughly speaking.
I was going to create a method for each of the different functions in both class, but I was wondering if it would be better to subclass for each function. I've never done this before, so it's a little confusing.
I'm not really sure what you are trying to do, the code is pretty sketchy. It looks like you want to have a bunch of queries on your dataset, and the result of each query is displayed in a window. Is that right? Assuming it is, I'll continue...
First, DO NOT put any references to your GUI classes into your data access classes!! NEVER ever do that!
Excuse my shouting, but it is a really bad idea. Your data class methods should return data, not GUI objects. The less the data classes know about the rest of the application the better.
Why? Because you want to be able to have different clients of the data classes. Here are some possible clients:
- unit tests
- utility programs that do some commonly needed manipulation of the database
- reporting package
- command-line clients
- alternate GUIs (maybe you decide you don't like PythonCard, do you want to rewrite your data class to work with Tkinter / PyQT / whatever?)
So, how should you organize this?
I would probably have
- a data access class (DAO)
- probably some data container classes (domain objects). Your data access class methods will take domain objects as parameters and return them as results. The different parts of the app will communicate by passing domain objects around. If the domain data is very simple you might just use Python lists and dictionaries.
- a class for the main window
- classes for the display windows - a separate class for each kind of display. If all the displays are similar you might reuse a single class; if they are very different they will have their own classes. If there is shared behaviour you might have a common base class, otherwise inherit directly from the GUI classes.
- possibly one or more controller classes - the classes that provide the glue between the gui and the data. Some of this logic will be in the main window, some you might want to put in its own class.
A sample data flow might be
- user enters a query into the main window and clicks a 'search' button
- the search button handler is invoked. This might be a method of the main window class, or it might delegate to a helper class.
- in either case, the handler class must have a reference to the data access class. It forwards the request to the DAO, gets the results back, and creates the new window to display the results. (The result object might be passed directly to the window class in its constructor or by a helper method.)
By the way, DAO is just one pattern for database access, there are quite a few others. In particulary Active Record is used by SQLObject - in this pattern the domain object itself knows how to interact with the database. You might like to look into this.
http://www.martinfowler.com/eaaCatalog/activeRecord.html
http://sqlobject.org/
Incidentally, is this
searchWin = genericChild
an OK way to create a class instance of genericChild? It seems to work OK, and Pythoncard does funny things with __init__ for windows ( I can't figure out how to pass __init__ arguments for example.)
No, this just makes searchWin an alias for the genericChild class, it doesn't create an instance fo the class.
BTW typical Python usage is for class names to use InitialCapitalLetters, e.g. GenericChild.
Kent
But I'm worried that there's some unforeseen consequence of this kind of thing, it just seems strange not finishing with ().
So yeah, should I do a method for each function, or subclass my generic classes?
Regards,
Liam Clarke
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor