Questions about app design - OOP with python classes

[Bruno Desthuilliers]

adriancico at gmail.com a écrit :
> Hi
> 
>     I am working on a python app, an outliner(a window with a TreeCtrl
> on the
> left to select a document, and a RichTextBox at the right to edit the
> current
> doc).
> 
>     I am familiarized with OOP concepts and terms but I lack practical
> experience
> , so any comment/tip/pointer to docs will be welcome.
> 
>     So far, I have created a separated class for each important
> element of my app
>         - the main Frame (cFrmMain)
>         - the TreeCtrl
>         - the TextCtrl at the right
>         - a cDocument class that contains the entire file with all
> docs
>           and manages creation/deletion/saving to disk, etc
>         - classes for the toolbar, the menubar, etc

As a side note : hungarian notation is usually considered bad form here. 
Look here for usual naming conventions:
http://www.python.org/dev/peps/pep-0008/

>     With this design, pretty much everything is encapsulated in it
> respective
> class. However, that means that the main program logic is in the Frame
> class.

What do you call "main program logic" exactly ?

>>From there, it instantiates the other classes and is responsable of
> the
> communication between them.
 >
>     For example, the user deletes a node on the Tree, this raises an
> event
> on cFrmMain (the main Frame class). In the event handler, cFrmMain
> notifies
> cDocument that a node (and the associated text) has been deleted so
> the master
> file is modified accordingly.

Ok.

>     The problem is, I have been implementing some funcionalities to
> test this
> design, I have less than a dozen operations implemented and cFrmMain
> has grown
> more than acceptable, starting to get confusing.

Ok.

>     This design feels "not quite right" to me,

Looks "almost right" to me !-)

Using the main frame as a mediator between the different widgets is a 
well-known design pattern, named - suprisingly - mediator. The 
motivation is that it avoid each and every widget to know about the 
existence of every other widget. You may want to read about this pattern 
- but note that most litterature about design patterns is expressed in 
terms of statically typed languages (Java, C++ etc), and that dynamic 
languages like Python usually don't need that much boilerplate and 
complication (IOW : try to understand the pattern itself, not to blindly 
apply it).

What's your looking for IMHO is the "controller" part - the one that 
glue together the "view" (main frame and all it's widgets) and the 
"model" (mostly, your document). Here again, googling for 
"model/view/controller" (MVC) may be a good idea.

> I've been considering
> allowing
> the different classes to know of the existence of each other and pass
> messages
> between them. I would lose encapsulation (I think),

At least this would introduce too much coupling between these classes.

Note that there's nothing Python-specific in your question. But since 
comp.object is one of the worst places on earth to ask questions about OO...