It is better practice to have one class ActionEventHandler which then has if..else statements to find the source of the event or is it better to have one class per event i.e okButtonHandler, cancelButtonHandler e.t.c ?
"One class per event". Wouldn't it be too much? Or maybe anonymous inner class! I was asking the same question to myself and I came to make only one class handling all the events! I'm not sure it's the best way, so I am waiting to hear more from the master!
By constantly trying one ends up succeeding. Thus: the more one fails the more one has a chance to succeed.
Joined: May 15, 2001
Just to clarify my first question. I meant one inner class per event. I have been thinking of using maybe one inner class per panel or menu. I really don't know which is the most efficient method. The problem I have with using just one event handler class is the amount of verification of the input fields that I perform. This leads to very a large inner class. The class I am writing has a very defined function and only uses a GUI to help the user input information which the function uses to obtain a desired result.(Which for clarification is a binary file to be used by another progam). [ March 27, 2002: Message edited by: Nigel Browne ]
This is one of those 'how long is a piece of string' questions It's amazing how many questions of this type do arise in programming. I guess it's one reason why programming is as much of an art as a a science. How you handle events is very context dependent and to a degree is a question of judgement and personal preference. Unless performance is critical, (and this is surprisingly rare), code readability is the primary criterion for deciding what to do. Handling a lot of events in a single event handler makes the code hard to read so it is generally better to split them up. Whether you handle 3 or 5 or however many events in a particular handler is a decision for a particular context. Go for clear coding as far as possible. Some people recommend a unique event handler object for each event. While this has the merit that the code for each event handler will be simpler than handling multiple events, it doesn't necessarily imply clear coding. For very large numbers of different events, the number of handler classes and objects in itself can make the code difficult to follow. I generally prefer sensible groupings of events - by menu or submenu for menu items for instance. Then you can usually have class and object names that identify reasonably clearly who is handling what. If you are after the ultimate in performance, you need to keep the event handling code as simple as possible. This will usually mean one handler per event. Another factor is what you plan to do in response to an event. Typically the event handler will be an object of an inner class for the object that is most affected by the event. It's by no means necessary to define an event handler as an inner class type. Sometimes a separate class type can be just as convenient, and then the class type is not buried inside another class. Don't forget anonymous classes either. For single events that require only a small amount of code, an anonymous class can be the most appropriate. I'm afraid this doesn't sound like a straight answer - probably because it isn't
Ivor Horton<br />Author of the Beginning Java Series including the new <a href="http://www.amazon.com/exec/obidos/ASIN/1861005695/ref=ase_electricporkchop" target="_blank" rel="nofollow">Beginning Java 2 SDK 1.4 Edition</a>
I can only mention how I generally do it. Lets say I have a JDialog box that has three buttons. In the code for the box, I put three accessor methods that return each button. Then, when I create an instance of the box in my main(or where ever) I can call the getButton methods and addActionListeners on each one there. I like to place the event handling code where it is going happen as opposed to over in the box code. HTH,
Jason R. Kretzer<br />Software Engineer<br />System Administrator<br /><a href="http://alia.iwarp.com" target="_blank" rel="nofollow">http://alia.iwarp.com</a>
Indeed, this can be a difficult question to answer in any sort of straight-forward way. I agree with Ivor in that this depends upon the context of your application. As application efficiency isn't generally of primary concern in the applications I write, I usually try to make any code as readable as possible. One approach that I use, which Ivor hinted at, is to group similar actions together in a single handler. Often, I find that I have a panel that will have two or three or four buttons on it. I try to make a single action listener for all of the objects on that panel. I've found that grouping objects by the panel or menu that they can be found in is often a logical way to group actions as items within the same panel or menu are usually related. Unfortunately, I don't think there is a single, correct answer for this. It can be done many different ways - you just need to decide which way is most appropriate for your application. I hope that helps, Corey
Thanks for the responses, I am leaning towards one handler for each logical group. It seems that there is no hard and fast rule to answer my original question. So I will work from the principles of keeping every as simple as possible, readable and maintainable. Sounds easy doesn't it [ March 27, 2002: Message edited by: Nigel Browne ]