Object-Oriented Programming in Java

A graphical user interface, or GUI, is the part of a program that shows windows, buttons, and other visual pieces on the screen. It is tempting to think of a window as something that is simply displayed and then waits passively. The source material makes an important point about this: a GUI does not respond just because a user looks at it. Something has to happen through interaction, such as a push button being clicked or a keyboard key being pressed. Those interactions are what generate events, and the program responds to the events it receives.

Follow one interaction from start to finish. A user clicks a push button on the window. The click is an interaction with a GUI component, and that interaction generates an event. The program does not simply see the click happen by itself. It receives a message about the event, which informs it that an event has occurred. Then the program responds according to the instructions it contains, and those instructions are carried out by an event handler.

Read the diagram from top to bottom. The user acts on the button, the button's interaction generates the event, the program is informed through a message, and the handler supplies the response. Each arrow is a step that happens in order, so the handler does not run until the program has received word that the event occurred.

Events are generated by user interactions with GUI components. The source names two examples. A push button may be clicked, and a keyboard key may be pressed. Both are actions a user takes, and both produce events. The source does not present these two as a complete list, so think of them as the standard illustrations of the principle: an interaction with a component is what creates an event.

An event that happens on the screen is not automatically understood by the program's code. The program is informed that an event has occurred through a message about the event. The program receives that message and then decides, according to the instructions it contains, how to respond. This two-part arrangement is the key idea: the interaction creates the event, and a message carries the news of that event to the program.

Notice what the message does and does not do. It tells the program that something happened. It does not itself contain the response. The response lives in the instructions the program holds, which is where event handlers come in.

An event handler provides the instructions for responding to an event. When the program is informed that an event has occurred, the handler is the part that says what to do next. The source also notes that a GUI program typically consists largely of event handlers. In other words, a large share of a GUI program's code is made up of these response instructions, one set for each kind of event the program needs to answer.

Now trace a few different situations side by side. The same chain of steps applies whenever an interaction happens: the interaction generates an event, the program receives a message, and the handler responds. When no interaction happens, the chain never starts.

The GUI components that appear on screen are not unrelated bits of decoration. Java GUI components are objects. Java provides many predefined classes, and each class represents a different kind of GUI component. A specific component on the screen is an object created from one of these classes. That is why the event ideas above, such as a push button being clicked, connect to objects in the program.

The diagram shows the two relationships the source describes. First, component classes relate to one another: some of them are subclasses of other classes, so they sit in a class structure. Second, an individual component you can see and interact with is an object that belongs to one of those classes. The source does not list the specific component classes, so the diagram stays general on purpose.