I just inherited a swing application from a former co-worker that uses a card layout.
It has about 40 different JPanel cards that are all static and make up the GUI.
Each of these static panels are a different class that has about 50 static variables each of their own and they all inherit from the same super class, which is a subclass of JPanel.
I plan to put as many of those 50 static variables and methods as possible into the parent class for readability.
My concern is that all these static variables and JPanels are sitting in memory when they don't need to be.
I would like to know if this is the way a screen-by-screen GUI should be created or if there is a more efficient way?
Off hand, it doesn't sound particularly elegant, but that doesn't mean it's a bad design.
As far as memory usage, 2,000 variables isn't a lot of memory, unless they are big data structures. I wonder how many of the static variables can be refactored. After all, static int sFoo; in two subclasses is two variables in memory, which might server different purposes. Putting them into the common super class means that there is now only one variable, and the (potentially) multiple purposes may now collide.
Also, efficiency is in the eye of the beholder. Without knowing the details, it's hard to say if a bunch of static panels is the most efficient way to initialize the app or not. Another type of efficiency is the use of your time. The issue, it seems to me, is whether it is more efficient to patch as needed to maintain the app or will it be more efficient to spend a lot of time up front refactoring, hoping for less time maintaining the app down the road. Who knows? My general philosophy for things like this is, "if it ain't broke, don't fix it".