Where is place for "Events" in an OOP script?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Where is place for "Events" in an OOP script?

GKalman-2
I'm trying to separate the GUI and Non-GUI type classes in my script. For example: Say, I have a Spring class ( with all the non-GUI type attributes of a mechanical Spring) and a DisplayBoard class (for all the Tkinter type displays on a Canvas object). For simplicity, assume I want to drag an instance of the Spring across the Canvas. Questions: (1) Do the actions defined thru the "bindings" and associated callback-functions "belong" to the Spring class or the GUI class? (2)Should there be a separate "Actions" class that ties the Spring (non-GUI) class and the DisplayBoard (GUI) class together?
Reply | Threaded
Open this post in threaded view
|

Re: Where is place for "Events" in an OOP script?

Wayne Werner
On Wed, Oct 5, 2011 at 11:26 AM, GKalman <[hidden email]> wrote:
I'm trying to separate the GUI and Non-GUI type classes in my script. For example: Say, I have a Spring class ( with all the non-GUI type attributes of a mechanical Spring) and a DisplayBoard class (for all the Tkinter type displays on a Canvas object). For simplicity, assume I want to drag an instance of the Spring across the Canvas. Questions: (1) Do the actions defined thru the "bindings" and associated callback-functions "belong" to the Spring class or the GUI class? (2)Should there be a separate "Actions" class that ties the Spring (non-GUI) class and the DisplayBoard (GUI) class together? 

Helpful tip: proper formatting (spaces between lines, numbered lists on separate lines) is helpful to us when we try to read your email.

To answer your questions, it depends on what pattern you're using. You might want to take a look at the Model-View-Presenter design pattern. There are several other patterns that help decouple your design, but to me this pattern sounds like it answers your questions. 

If you use the MVP pattern, the View would be your GUI (at least in this case). From what I understand, in the most "pure" version of MVP, the only thing the view does is display data, and pass events to the presenter. The presenter is where all the logic (i.e. "Doing stuff") happens.

In your particular example, it sounds as if you have "things" that you're moving around on a "board". So from an MVP standpoint, your presenter might have a Board instance. That Board would have its dimensions and any other attributes it might need, and possibly a collection of items that are on the board. Then the View will have access to the Board via the presenter, and based on the data in the Board object and the items it contains, it will draw certain things.

Then depending on how strict you want to adhere to the MVP pattern, when you click and drag an item, you might bind the MouseDown event to presenter.selectItem(x, y) - and the presenter would set its .active_item to the item at (x,y). Then you would bind the MouseMove event to presenter.move_item() that might take either an absolute x,y position or a delta-x/y. Finally, you would bind the MouseUp event to presenter.release_item() that would set the .active_item to None.

The beauty of this pattern is that now you can easily plug-and-play with different views. Instead of using Tkinter, maybe you want to use PyGTK - that's fine, no real problems. Just implement the right events that call the right methods. Maybe instead you want to create a text based interface like the old RPG, so you could have something like this:

> look around
You see a spring.

> eat spring
You cannot eat spring.

> touch spring
Spring is hard and metallic.

> grab spring
You are now holding a spring.

> move north
You are standing in front of the door.

> drop spring
The spring bounces in front of you, coming to a halt.

> taunt spring
The spring does not respond to your taunts.


And grab, move, and drop springs would simply call functions on your presenter.

Or on a more serious nature, you could also write automated test cases using unittest or nose or one of the other automated test tools, which are invaluable when you want to make sure that your program works correctly.

It takes a little practice to get the hang of writing code that way - Test/Behavior Driven Development helps - but the payoff of having decoupled code is quite valuable.

HTH,
Wayne

_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Where is place for "Events" in an OOP script?

Gregory Ewing
In reply to this post by GKalman-2
On 06/10/11 05:26, GKalman wrote:
> (1) Do the actions
> defined thru the "bindings" and associated callback-functions "belong" to the
> Spring class or the GUI class?

The functions bound directly to input events such as mouse clicks
and movements should probably be part of the GUI. You will probably
want to perform some processing on them before doing anything to
the model, such as transforming from pixel coordinates to model
space coordinates and maybe other things.

> (2)Should there be a separate "Actions" class
> that ties the Spring (non-GUI) class and the DisplayBoard (GUI) class together?

That's hard to answer without knowing a lot more details about
the application. Use one if it helps, but don't feel obliged to
include one if it doesn't seem to be adding any value.

--
Greg
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss