New event Model (Java)

The component of the new event model can start an event. Each type of event is depicted by a different class. When the event begins, it accepts one or more events to indicate "sink". Therefore, the event source and address of the processing event can be detached.
Each event sink is a class object that executes a specific sink type interface. So as a program developer, all we have to do is create the receiver object and register it in the component of the activated event. The event-firing component calls a Addxxxlistener () method to complete the registration to describe the XXX event type acceptance. We can easily learn that the addlistened name method informs us that any event type can be handled, and if we try to receive events we will find our errors at compile time. The Java beans also uses this AddListener name method to determine which program can run.
All of our event logic is loaded into a sink class. The only limitation when we create a receiver class is that we have to perform a dedicated interface. We can create a global receiver class that helps to be well used in internal classes, not only because they provide a theoretical receiver class group to the UI or business logic classes they serve. But because (as we will see later in this chapter) the fact that an inner class maintains a handle to its parent object provides a good way to invoke the class and subsystem boundaries. A simple example of
will make all this clear. Also consider the difference between the previous Button2.java examples in this chapter and this example.
 

: Button2new.java//Capturing button presses import java.awt.*; Import java.awt.event.*;

Must add this import java.applet.*;
  public class Button2new extends Applet {button B1 = New button ("button 1"), B2 = New button ("button 2");
    public void init () {B1.addactionlistener (New B1 ());
    B2.addactionlistener (New B2 ());
    Add (B1);
  Add (B2); Class B1 implements ActionListener {public void actionperformed (ActionEvent e) {getAppletContext (). Showsta
    Tus ("button 1"); The class B2 implements ActionListener {public void actionperformed (ActionEvent e) {getAppletContext (). Sho
    Wstatus ("button 2"); }/* The old Way:public boolean action (Event evt, Object Arg) {if (Evt.target.equals (B1)) Getappletcont
    Ext (). Showstatus ("button 1");
    else if (evt.target.equals (B2)) getAppletContext (). Showstatus ("button 2");
    Let's base class handle It:else return Super.action (EVT, ARG); return true; //We ' ve handled it here} */}///:~ 

We can compare two methods, the old code on the left as an annotation. In the Init () method, only one change is added to the following two lines:
B1.addactionlistener (New B1 ());
B2.addactionlistener (New B2 ());
The addActionListener () Notification button object is activated when the button is pressed. The B1 and B2 classes are internal classes that perform interface ActionListener. This interface includes a single method actionperformed () (this means that the action will be executed when the event is activated). Note that the actionpreformed () method is not a trivial event, and more appropriately it is a special type of event, ActionEvent. If we want to extract special actionevent information, so we do not need to deliberately test and retrace the form of the argument.
One of the best things for programmers is that actionperformed () is very easy to use. It is a method that can be invoked. Compared to the old action () method, we have to point out what happened and the appropriate action, and we worry about invoking the version of the underlying class action () and returning a value to indicate whether it is being processed. In the new event model, we know that all event test inferences are automatically carried out, so we don't have to point out what happened; we just said what happened and it was done automatically. If we have not come up with a new way to cover the old ways, we will come up soon.