Fog Creek Software
Discussion Board




GUI and OOP

This question has been bugging me for quite a while.

A GUI is usually event-driven. In a medium-sized software, there are usually tens of GUI components. Some of them are active and can fire events. Some other components' state may be changed as a result.

My question is: What is the best way to implement this in the OOP paradigm? How to avoid or minimize coupling? Sometimes an UI component is a member of another component, but both the "child" and the "parent" components may interact with each other. In this case the parent has to pass a pointer or reference to itself to the chile object. Is it the only way to do it?

Maybe this question is too lame, no book I found discussed it.

Sam Wong
Sunday, May 26, 2002

Take a look at Constructing the User Interface with Statecharts by Ian Horrocks. It was a big help to me a few years back when I was maintaining/rewriting a complicated inventory management system. The forms had many GUI controls whose state would depend on the state of other controls, and the code that enforced all this was bewildering because it was spread across the event handler methods. 

Horrock's book shows how to think of the user interface as a state machine, with user actions triggering transitions between states. Transitions are handled in controller classes in response to simple calls from GUI event handlers. The resulting code is much clearer and easier to maintain.

The technique is fairly rigorous, involving the creation of UML statecharts before writing code. I'll admit that I didn't always do that, for the usual reasons one doesn't maintain UML models. Some readers may see the book as a top-heavy way to do MVC.  But it provides a usefull alternative to the haphazard, non-OO approach you see in many Delphi/VB applications. 

Scott McKissock
Sunday, May 26, 2002

Do you know the MVC (model-view-controller) design pattern?  If not, Design Patterns carries a good explanation, or searching on MVC.

http://www.object-arts.com/EducationCentre/Overviews/MVC.htm

belize visitor
Sunday, May 26, 2002

Design Patterns.  Gang of Four!

The Raging /.'er
Sunday, May 26, 2002

Publish/Subscribe, which sometimes takes the form of Signals & Slots, is an excellent decoupling strategy; When implemented correctly, it doesn't even hinder performance. Have a look at Qt [ http://www.trolltech.com ] for an example of how this fits in an OO paradigm.

Ori Berger
Sunday, May 26, 2002

My favorite way of decoupling these components is through a signals and slots mechanism (the type used by the QT toolkit). Signals and slots prevent you from having to use janky callback handlers that may or may not have to be passed to the firing element.

Check the Trolltech site for more information on how signals and slots can make your life that much less painful.

Alex Russell
Sunday, May 26, 2002

"But it provides a usefull alternative to the haphazard, non-OO approach you see in many Delphi/VB applications. "

Ouch.  When I abandoned VB years ago, it was not OO (even though MS though it was). Still not sure if VB 6 is really an OO language yet...I'll find out in July when I get thrown back into it after a 6 year absence.

Delphi on the other hand, has always been OO.  Whether you are dealing with a class, or a grid on a screen, they are true objects.

Brad Clarke
Wednesday, May 29, 2002

*  Recent Topics

*  Fog Creek Home