As you saw in the previous section, centralised event handling sucks quite a bit. It scales badly and you can only really identify components by text strings(!). Before I get into the nitty-gritty of event handling without stupid ifs...heres a quick commercial break brought to you by a pair of Classes.
Wow. Well thats...different. Basically, you are allowed in Java to embed Classes inside of other Classes. These inner classes have a few special properties of their own that you ought to know about. With the inner classes, private fields from its outer class may be used, completely breaking the lovely model you currently have of public/private/protected. You will also note that the inner class has no constructor. This is because it is designed to be used for single-shot anonymous objects that you do not assign to variables or anything of the sort. In fact, (As far as we know so far, at least) the main reason Inner classes were introduced to the Java language is because the centralised method of event handling sucked horribly.
So what the hell does this all have to do with GUIs?! Well, maybe the following code snippet may help. Once again, this is taken from the lecture slides.
Right. Confused? Good. First of all, remember that openItem is a JMenuItem and that the addActionListener method tells java that it should tell this class whenever something happens to this object. Think of this whole thing like openItem.addActionListener(zomglotsofstuffhere); and things get a little bit clearer.
The inner class here (Called ActionListener) has a single method called actionPerformed, as with the awful style of event management. Inside this method everything that needs to be done when this event is fired off is written. This style of event management is quite nice, although I expect with a lot of GUI controls the GUI code could become pretty long. However, with the amount of controls we will be using I do not see this as being a problem.