For real big projects look at n-tier application architectures, not at
some GUI implementation details. These architectures are based on the
idea to separate presentation and application logic (and, depending on
the number of tiers, other things).

Once you have set up you architecture you can use the stuff in Java's
GUI system to implement the presentation logic part.

For medium size projects you might want to study the MVC
architecture/design pattern in some detail, and cross-check that with
how Swing implements a variant of MVC. Instead of talking about data
storage variables you will talk about models.

The groups FAQ contains pointers to a Sun paper about the Swing MVC-like
architecture.

/Thomas

The most important thing you can do is make this decision *before* you
start thinking about the GUI code.  Your data structures and storage
should be completely independent of the user interface.  (Of course, if
the data is state of other user interface components then this becomes
more fuzzy; nevertheless, the concept holds... data belongs where it
will be used, but where it's being displayed to the user).  As for how
to get a GUI component to display that data, there are two methods that
can be used:

1. For simple cases where there's a clearly defined starting and ending
point for changing data, such as in a modal dialog box, you can put the
data into the GUI controls as you set up the dialog box, and then read
it back into the real data structure when an "ok" button is pressed.

2. For more advanced data that needs to be displayed and updated in real
time, there's a technique called a "model adapter", whereby you develop
a kind of bridge class that implements a GUI component's model interface
(which all Swing components have) and then propogates the changes to an
underlying data structure of your own choosing.

You probably don't want to keep all state in the main frame class (and
its questionable whether you even want to have a main frame class),
because as you noticed this will get out of hand very fast.  So,
essentially, pretend your writing the application without a user
interface, and then use the techniques above to fit the user interface
onto the code.

I provide a presentation about Swing data binding
with a chapter about a 3-tier client architecture.
See http://www.jgoodies.com/articles/

At the end of the slides you can find references
to other projects that use a similar approach,
as well as references to different concepts.

Just as a side node, often you can just use a JFrame;
there's no need to subclass it.

Best regards,
Karsten Lentzsch