RE: [ajug-members]: Sharing data among Swing windows

["Burr Sutter" <sutter@bravepoint.com>]

You described singleton fairly well.
Here is a link to an article on that one.
http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html
It is very useful for keeping up with "global" data.  I believe it's scope
is limited to the classloader and you normally use the default one making it
JVM global.  I've not tested it with multiple classloaders.

For constants use static final variables.

For "properties" that can change dynamically at runtime and have an impact
on other running programs I've used the "observer" pattern.
Article on that topic:
http://www.javaworld.com/columns/jw-java-design-patterns-index.shtml

You can combine the singleton and the "subject" (aka event source, message
generator) of the observer to make changes to global data broadcast to all
active windows.

I've had user requirements to allow windows to be dynamically linked.
Something like a customer inquiry screen allows the user to find a specific
customer record.  Selecting a customer dynamically syncs up with the order
history and accounts receivable screens running in the background.  

Burr

-----Original Message-----
From: John Wells [mailto:jb@sourceillustrated.com] 
Sent: Monday, May 31, 2004 11:25 AM
To: ajug-members@ajug.org
Cc: ajug-members@ajug.org
Subject: RE: [ajug-members]: Sharing data among Swing windows

Stefan Baramov said:
> John,
>
> You can use Singleton [GoF95] to share global objects. Luckily, Swing is a
> single threaded so you would not need to synchronize your global objects.
> Another useful pattern is the Madiator [GoF95]. You can read about these
> patterns in books such as "Patterns in Java" , ISBN 0-471-25839-3
>

Ah, ok...so let me make sure I follow.  Taking my example, I could create
a Connector class that implemented the Singleton pattern and would handle
requests from various Swing windows.  The Connector class would maintain
one static field that contained a static instantiation of itself and that
its constructors could check to see if it was already instantiated.  If it
was, then return a reference to that static field, else, instantiate,
store a ref in that static field, and then return a reference.

Is that on correct?

What about application contants such as log file name, common directory
paths, etc.  Would it be best to create an AppConfiguration class (also
implementing the Singleton pattern), have it abstract out the method by
which you store the common data (properties file, etc), and have all of
your other classes (windows) query it for the info?

Thanks for your continued help.

John