Swing best practice - private modifier vs. many parameters

Question

Dear Experts,
I have a comboBox that has a customized editor and has KeyListener that responds to several keyPressed and keyTyped. The comboBox is used in two different JFrame, say JFrame frmA and JFrame frmB.
Since the KeyListener changes the state of 8 other components in frmA, I have two options:
Option 1:
- Coding the comboBox in separate class and pass all components as parameters. I will have around 10 parameters, but the components can be made private to frmA or frmB.
Option 2:
- Coding the comboBox in separate class and pass the instance of the caller (frmA or frmB), so that the comboBox can change the state of the other components in frmA or frmB according to its caller. However, the components must not be private and should be able to be accessed by the comboBox class.
My questions:
1. I have not implemented option 2, so that I have not proved that it will work. Will it work?
2. Which option will be more efficient and require less cpu time? If it is the same, which option is the best practice?
3. Is there any other option that is better than these two options?
Thanks for your advice,
Patrick

Answer 1

Option 2:
- Coding the comboBox in separate class and pass the instance of the caller (frmA or frmB), so that the comboBox can change the state of the other components in frmA or frmB according to its caller. However, the components must not be private and should be able to be accessed by the comboBox class.
My questions:
1. I have not implemented option 2, so that I have not proved that it will work. Will it work?It doesn't stand in the long run. Doing so couples your specific ComboBox classes to all widgets that react to the ComboBox changes. If you happen to add a new button is either JFrame that should also be affected by the combo-box selection, you'll have to modify, and re-test, the ComboBox code. Moreover, if a new button was needed in one the JFrame but not the other, you'd have to introduce a special case in your combobox code.
Instead of the ComboBox's listeners invoke methods on each piloted widget, have them invoke one method (+selectionChanged(...)+) on these widget's common parent (not necessarily a graphical container, but an object that has (maybe indirect) references to each of the dependant widgets).
2. Which option will be more efficient and require less cpu time?I wouldn't mind.
In the graphical layer of an application, and unless the graphcial representation performs computations on the bitmap, any action is normally much quicker than business logic computation. Any counter-example is likely to be a bug in the UI implementation (such as, not observing Swing's threading rules), or a severe flaw in the design 'such as, having a hierrachy of several hunderd JComponents,...). Swing widgets are pretty reactive to genuine calls such as setEnabled(), setBackground(), setText(),...
If it is the same, which option is the best practice?Neither. Hardcoding relationships between widgets may be OK within a single, and single-purpose, form.
But if you want to code a reusable component thoug, design it for reuse (that is, the less it knows about how which context it is used in, the more contexts it can be used in).
In general, widgets that know each-other involve a quadratic number of references that accordingly impacts the code readability (and bug rate). This is the primary reason for introducing a Mediator pattern (of which my reply to 1 above is a degenerate form).
3. Is there any other option that is better than these two options?Yes. Look into the [+Mediator+|http://en.wikipedia.org/wiki/Mediator_pattern] pattern (the Wikipedia page is not compelling, but you'll easily find lots of resources on the Web).