2

I was developing a swing application which calls multiple methods & initializes different classes. Also I have multiple threads in which they process intermediate results. My requirement is to display that intermediate data on some labels and text boxes on the fly.

Please help me which of the below approach is best in terms of memory and performance.

  1. I can have setter methods for all my labels and text boxes. So that I can call these methods using that swing class object but in that case I need to pass the swing class object to every class wherever I want to set the data to labels.
  2. Another way is I can create public static object of my swing class and I would call it from any class whenever I need to set the label text.

First method creates more overhead as I need to pass the my Swing class object to other classes.

Second method is easiest way but creating static objects might create confusion as this application contains threads.

I just want to know which one to go for and why?

Otherwise if anybody have worked on some complex swing app development - how did you manage these kind of issues?

Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
Vasant
  • 301
  • 4
  • 14
  • 4
    Forget about your second method. It's ugly. There shouldn't be so many different objects needing to update a given frame or panel. – JB Nizet Jul 08 '12 at 17:15

3 Answers3

3

This example is typical of your first approach in a multi-threaded context. For expedience, the model and view are tightly coupled: each worker thread receives a reference to the label it should update. The alternative is loose coupling: each view registers to listen to the model, which notifies all registered listeners using the observer pattern.

This simpler example uses both approaches:

  • Tight coupling: The worker obtains a reference to its target label in an enclosing scope.

  • Loose coupling: The enclosing view registers a PropertyChangeListener, which the model uses to signal the view via setProgress().

You'll need to decide which is important in your application. I agree with @JB Nizet's comment about the second approach.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
1

Why dont you use the 2nd method with Singleton principle, where you can use the same single instance of the swing class, so there will be no use of using static , and its sometime confusing cause we are uncertain of the order in which the JVM loads the static members...

Kumar Vivek Mitra
  • 33,294
  • 6
  • 48
  • 75
  • How do you plan to implement your singleton without using a static field? – JB Nizet Jul 08 '12 at 21:06
  • There will be only one static field in the whole class and that will be the instance itself. Other field need not be static at all. For further details please see the Head First Design Pattern's Singleton chapter... – Kumar Vivek Mitra Jul 09 '12 at 02:52
1

Think of a GUI as a model with a view. The GUI components make up the view, while you create model classes that represent the model. Changes to the values in the model are reflected in the view. The rest of the application interacts with the model, and not the view.

Here's one example from a Java Spirograph GUI that I did.

Community
  • 1
  • 1
Gilbert Le Blanc
  • 50,182
  • 6
  • 67
  • 111