[Tutor] communication between class instances

[Magnus Lycka]

At 11:38 2002-12-07 -0700, Poor Yorick wrote:
>This is the first complete Python program I have attempted, and for the 
>experience I am trying to do things like have multiple interfaces using 
>different GUI tool kits and building all my own complex widgets.

Hm... Remember the KISS principle: Keep It Simple, Stupid! ;)

>You're right, I have many questions about event-based programs.  You 
>mentioned "a general rule of just calling logic from the GUI and not vice 
>versa."  This is interesting because most of the time, my program logic is 
>making calls to the GUI.  For example:

:(

>dbName = self.__activeUi.call(cmd='DbName', master=self.__activeUi.parent)

I'm not sure what this means, but I suppose you have entered a
database name in a GUI control. What I would do, would be to
give that data to some object in the logic layer as soon as the
data is entered correctly.

>In your PyCalc example, the Calculator becomes a component of MyFrame. 
>This component receives three hooks (is that the right word?)

I know what these three things are, but I'm not sure
what you are supposed to call them. :)

>back to MyFrame, enabling two-way communication.

I only do this because of one unusual circumstance:

The GUI code itself doesn't know what it will look like.
It places buttons on the window based on information from
the "logic". You could say that the pycalc module is
not just program logic, but also knows an abstract layout
and function of the GUI. This is unusual, and generally
not a good idea. If this generic GUI feature is desired,
it should probably be another layer separate from the GUI
and from the logic, but in most cases it's probably better
to simply rewrite the GUI from scratch if it is to be
changed. In the pycalc example, the real "business logic"
really boils down to a single eval function, so it's not
much point in separating that... :)

But in this case, it means that the GUI layer doesn't
know when to expect display changes, popup windows etc.

Normally, the GUI knows what every control is for, and
what to expect from every call to the logic layer.

In general I don't think this "hook" style is good. Maybe
it was a bad example. (Although I got a chance to discuss
the issue!)

As you see though, the pycalc module knows extremely
little about the GUI layer. It gets three functions, and
it knows when to call them. In two cases it sends a string
to the function, in the third, it doesn't care about parameters
at all. In no case does it know anything about any further
structure or parameter names in the layer above it. There is
nothing close to the level of coupling you present in:

self.__activeUi.call(cmd='DbName', master=self.__activeUi.parent)

It seems to me that code like that in the logic layer means
that you are either helplessly tied to a particular GUI and
that your GUI related maintenace problems will spread further
than they should, or that you will need to build your GUIs
more complex than you would otherwise.

All too tight coupling.

>Now if calculator itself had a sub-component (class instance), which 
>itself in turn had a subcomponent (class instance) which needed feedback 
>from the user, I suppose that generally, it would be best for each 
>component to communicate with its parent component via supplied hooks, and 
>thus relay the message up to MyFrame.  Is that true?

No. The event mechanisms in the GUI (in other words, user actions)
should drive the logic. Not the other way around! The logic should
normally communicate with the GUI layer by return values or exceptions
only. Like in my first, tiny example.


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se