[EMAIL PROTECTED] 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... -- http://mail.python.org/mailman/listinfo/python-list