Anonymous Classes question

[Brandt Charles]

I'm taking an Intro to Software Engineering class using Java and we just covered GUI's. This is the first I had heard of Anonymous Classes so I thought I'd post my question here. Anyway, the text mentions Anonymous Classes should only be used if the event handling code is only very small such as one line. Is this a hard and fast rule? GUI programming appears to be a bit cumbersome (see my sig), so if the code is clean, why couldn't one use anonymous classes other than under this condition as mentioned by the text?

Furthermore, what would be the good rule of thumb on using Adapter Classes versus the regular, longer way of programming event handlers?

I appreciate the help and resource. It's never fun to post programming questions on angry forums such as those on Anandtech as the inevitable accusations of free homework help arise.

[Joe Ess]

You are hardly the "greenest" if you are talking anonymous classes.

Originally posted by Brandt Charles:
. . . Anonymous Classes should only be used if the event handling code is only very small such as one line. Is this a hard and fast rule?

There are few "hard and fast" rules. My standard has always been that code "works and can be seen to work".
GUI construction code in Java can get pretty ugly. Adding a bunch of anonymous event handlers into the mix doesn't help. By making the anonymous class one line (usually a call to some method which contains the details of handling the event) you can keep your construction work seperate from the various run-time events. That makes your code easier to read and maintain, and is therefore a good thing.

It's never fun to post programming questions on angry forums such as those on Anandtech as the inevitable accusations of free homework help arise.

We try to keep it friendly around here.

[Campbell Ritchie]

I am sure I have written about anonymous inner classes as ActionListeners before. Of course, other Listeners, as well as Runnables can also be anonymous.

I use the rule of thumb that if you have more than one Listener which do the same thing, or something very similar, use a named class, and pass the differences in the constructor; the classic example given in beginners' exercises is buttons which change their colour; set up this sort of thing:-

redButton.addActionListener(new ColourListener(Color.RED));
 . . .
greenButton.addActionListener(new ColourListener(Color.GREEN));
 . . .
private class ColourListener implements ActionListener
{
   public ColourListener(Color myColour)
   etc etc
}

I don't like the

addActionListener(this);    

format which is found in some books; it might be simple to learn, but if you have more than one button, you can end up with so many if elses and else ifs, that the actionPerformed method looks a right mess. I only use the (this) technique when it specifically refers back to your Component (eg add a MouseMotionListener to a panel which displays the mouse co-ordinates on a text field).

The anonymous inner class is useful when you have one component with a unique action. An example using an exitButton:- [But if you have an exitButton and an exitMenuItem, don't sue anonymous classes, use an ExitListener class, otherwise you are duplicating things.]

Stage 1:
exitButton.addActionListener();    

Stage 2: put two new lines in the ()

exitButton.addActionListener(
 
);    

Stage 3: fill in the gap.

exitButton.addActionListener(
   new ActionListener()
);    

Stage 4: ActionListener is an interface; make it into a class body with {}.

exitButton.addActionListener(
   new ActionListener()
   {
   }
);    

Stage 5: ActionListener must have one method, with the signature as below. It would be more complicated if we used .addMouseListener() because MouseListener has to have five methods

exitButton.addActionListener(
   new ActionListener()
   {
       public void actionPerformed(ActionEvent e)
       {
       }
   }
);    

At this point (and not before) you can persuade the compiler to accept it, but nothing will happen until stage 6: Fill in your method body.

exitButton.addActionListener(
   new ActionListener()
   {
       public void actionPerformed(ActionEvent e)
       {
           System.exit(0);
       }
   }
);    

And as Joe Ess has told you, putting in a call to another method rather than lots of coding will make it simpler to see what is going on.
I hope that is of some use to you
CR

[Brandt Charles]

Thanks for the replies, they were helpful. It is nice to see someone with more experience than me not fond of the (this) way of coding the listeners. Unfortunately, some books held in high esteem teach that as the primary way of doing it. The text used for my class teaches the long way, then also using Adapter and Anonymous classes.

[Rakesh Chaudhary]

Thanks for giving such a awesome explanation..it wouldn't have been more clearer than this......

Thanks and keep living on the EDGE......

[Minh Nam]

Thanks guys for the useful discussion. It is valuable for me although it was 5 years ago

[mike ryan]

Hi,

I was refered to this older post so i wanted to add a comment/ question to it. I tried this on something i am working on now instead of using an inner Class as i usually had. I had an ActionCommand set for the button but
as far as i can tell after commenting it out, i no longer need an ActionCommand as when the button is clicked it goes straight away to the "actionPerformed(ActionEvent e)" method.
Is this correct , or are there cases where i will still need to set one using this type of ActionListener set-up?


Thanks
Mike

[Ranganathan Kaliyur Mannar]

With reference to your other post, when you set the ActionCommand, instead of calling e.getSource().equals(), you can use e.getActionCommand().equals("SaveAction")...

the former compares objects and the later Strings...so, if you compare using e.getSource(), setting the action command makes no difference to your program. And all this is needed if you have only one ActionListener for your entire class.

As pointed out in the other post, that is not a recommended way of writing ActionListeners.

[Rob Spoor]

And if you use an action listener for only one component (as is the case with anonymous listeners) then no, you don't need the action command. I hardly ever set one.

[mike ryan]

Hi,

Thanks to both of you for your comments! I like this style actually, and i will probably appreciate it more with a larger more complex program. Although i think this will take up allot more space then the way i am learning now
if there are a bunch of buttons and so on. But possibly much easier to read and comprehend.

Thanks
Mike

[Campbell Ritchie]

Button: an object.
Connects to a Listener: an object.
These two objects relate to each other, and one implements the behaviour the other offers.
One button and one listener. It may means there are more classes, and more objects, but those classes are small and easy to read. Remember memory is cheap nowadays; I spent some time this morning creating 8800000 Integer objects, accompanied by 8800000 Map.Entry objects which nobody noticed.

Many buttons, one Listener. An impenetrable mess of if-elses, difficult to update if you change the button. Lots of comparisons for equality before you find the required block.
Somewhere on the Ranch there is an example from about 3 years ago. Somebody created a calculator, with an enormous actionPerformed() method, full of things like

. . . if (((JButton)source).getText().equals("3"))
{
   number = number * 10 + 3;
}
else if (((JButton)source.getText().equals("4"))
 . . .

It wasn't exactly like that, but similar. I haven't found it recently. I didn't have the heart to tell the rancher how much of her time they had wasted writing that method.

Just think how much easier it would have been with

public class NumberListener implements ActionListener
{
   private final int number;
   private final Calculator calc;

   public NumberListener(int number, Calculator calc)
   {
      this.number = number;
      this.calc = calc;
   }

   public NumberListener(String number, Calculator calc)
   {
      this(Integer.parseInt(number), calc);
   }

   public void actionPerformed(ActionEvent evt)
   {
      calc.addDigitToValue(number);
   }
/* equals() toString() hashCode() methods, etc */
}

Now you can set up the buttons in a loop, using the loop index to initialise the buttons and the listeners simultaneously.