Re: Design with a GUI
banansol@hushmail.com wrote:
Hi,
I wonder how one should design programs an OO way when you want to
have a GUI (Swing). Let's take a simple example, say I'm making a
program that checks if a list of servers are up. If I don't think
about the GUI I could make a Server class, and then some class
ServerCheck (or something) that contains an array with Server objects
and metods that can check if they are up and so on.
But now if I want to have a GUI, say, a JPanel that conains a JList
that has all servers in it, how should one design that? Should I
continue from where I am now in the design process and add classes
that inherit from JPanel and such, or should I right from the
beginning take the GUI into consideration and maybe make the
ServerCheck class inherit from JPanel and add GUI components to it?
But that would end up with a class containing both components and the
array of Servers. Is that a good way? I think it looks messy, I want
to separate them. But I have no idea what's best.
So I wonder how to do this. Please give me some examples how you would
design such a thing.
One way to proceed (and it's a fairly useful way) is to
keep Server and ServerCheck and their allied classes "GUI-free:"
Just let them do their job of monitoring the servers and keeping
track of their state. Then write the GUI part as "work-free:"
its only job is to query Server et al. and display the information.
Server and co. are the "model" that holds and maintains the data,
while the GUI is the "view" of that data.
You may be wondering how the GUI decides when to query Server
for new information to update its display. There are two main
approaches here: the GUI can wake itself up every T seconds to
retrieve the Server's current information and display it, or the
Server can notify the GUI when something "interesting" happens.
A good way to make the notification work is to give the Server a
method like addChangeListener(), allowing "outsiders" to register
their interest in being informed of changes. The GUI calls this
method to attach a ChangeListener (you could use some other kind
of event if it seems more appropriate), then sits back and waits
for something to change.
The reason I like this approach is that it separates the
presentation and the maintenance of the data. If you decide to
change the GUI -- for example, you might develop a small-screen
version for a mobile device -- you can do so without disturbing
any of the Server code that does the real work. Indeed, you can
implement several different GUIs, all attaching in the same way
to the same instance of Server. You can even implement non-GUI
listeners: For example, you might have a listener that formats
the information to HTML and updates a page on a Web server, or
you could write a class that listens to Server and pages someone
if it detects a crisis.
There are many possible ways information might be used, once
gathered. Keep the gathering and the using separate, and you'll
have a lot of flexibility in choosing.
--
Eric Sosman
esosman@acm-dot-org.invalid