[ruby-talk:12335] Re: Understanding Design Patterns Was: GUI Toolkit for Ruby

[e-mail] wrote in message
<[e-mail]>...
>Hi all,
>
>I bought the Gang of Four's "Design Patterns" book the other day,
>and, as probably has happened with many people, I was inspired.
>
>Near the beginning, it talks about designing for easy portability
>between windowing systems, and thus introduces the Composite and
>Bridge patterns.  Anyhow, the basic idea is that you write a
>generic Window class, for instance, which acts as a wrapper to
>whatever GUI Toolkit is desired at the moment.

The GUI Toolkits (FOX, GTK, Tk, XVT, Zinc, etc.) have basically used the
approach described to build a higher level abstraction on top of the
operating system specific windowing systems. This works because at the
low level, most windowing systems are sufficiently similar.

It is kind of hard to do this again because the abstractions these GUI
toolkits expose are different. Some expect you to provide callbacks for
the relevent functionality, others send you a stream of "normalized"
windowing events, others expect you to manage the event loop in your own
code.

While someone could possibly build a really generic interface to all of
the libraries, I'd suggest that a clean separation between the
presentation logic and everything else is a better way to go.

The Facade design pattern kind of explains this, but it is shown much
better in Martin Fowler's "Analysis Patterns" book. The idea is that you
provide a Facade that can be used to drive your application. Then you
craft whatever user interface you want (Command line or GUI) and that
then drives the application using the methods exposed by the Facade.

If you do this right it is then a relatively simple task to put a
different user interface on the application.

Pete
----
Pete McBreen, McBreen.Consulting , Cochrane, AB
email: [e-mail]    http://www.mcbreen.ab.ca/
Software development is meant to be fun,
     if it isn't the process is wrong