[wxpython-users] Re: code structure - suggestions? (classes for gui, data, calculations...)

[Don Dwiggins]

Peter Damoc wrote:
> To split the code, write the screenplay of the program. Who is doing 
> what with what. And find out the main actors, the main props, etc.
> 
> Most of the time you will have a Sender, a Receiver, a Message and maybe 
> some kind of MessageTranslator. Each of these 4 players should be 
> isolated. It is ok for them to start up in one file, but if they grow 
> too big and interact with too many other players, give them their own 
> home. If they can form a "syndicate"... give them their own namespace. 
> i.e. you can delegate the translators in their own namespace.
> 
> Look for separation anxiety. If you find separation anxiety in a piece 
> of code, refactor it.
> This is easily detected by asking the question: What if this piece of 
> code would be in another [part of the file | file | package | folder | 
> whatever]?
> 
> If you hear the code screaming "Oh NOOOO!".... you should refactor.
> This is the Ravioli way. :)

Nice exposition.  It's also very similar to Martin Fowler and Kent 
Beck's approach in the book "Refactoring: Improving the Design of 
Existing Code", but instead of "screaming code", they talk about "code 
smells".

One other MVC bit: I like to have "active" buttons on my forms, in the 
sense that each one is only enabled when it makes sense for the user to 
push it.  (E.g., a Save button should be disabled until the user makes a 
change worth saving.)  Among other things, this avoids the need to write 
checking code in the button handler to pop up error messages when the 
button is pressed under the wrong circumstances.

The problem I've run into with this is the need to check all the button 
states after each "significant" change to the form.  The solution I came 
up with was to incorporate the buttons into the MVC structure.  In 
effect, a button is a view on a Boolean method of a model; when the 
method returns true, the button is enabled.  To do this requires some 
setup, registering each button as an observer of the model, and 
arranging for the model to notify its observers when any change to the 
form occurs.  Once set up, though, it becomes easy to manage the states 
of any number of buttons.  If anyone's interested, I'll write up a short 
description of my implementation of this.

-- 
Don Dwiggins
Advanced Publishing Technology