
          How To Handle Event Handlers

There are two orthogonal concepts to deal with when learning
event driven GUI programming. One "dimension" to learn along is
in the direction of all the different events that are possible
in the GUI system (e.g., mouse, key, timer, text, adjustment,
action, etc., events). The other "dimension" to learn along is
in the direction of all the different coding styles that event
handlers can be written in.

This folder demonstrates one of these dimensions and keeps the
other dimension fixed. In this folder we see many possible
coding styles for event handlers. Every program in this folder
handles the same kind of event, a button event. Each example
program is essentially the same program, a button that, when
clicked, changes the color of a panel.


An event handler is part of the Controller in the MVC pattern.
As we saw earlier, the Controller needs to communicate with both
the Model and the View. The Controller needs to update the Model,
and then the Controller needs to signal the View to repaint itself.
In the examples in this folder, we look at several coding styles
for establishing the communication between the Controller object
and the Model and View objects (the communication between the View
object and the Model object can be handled in similar ways).

There are two basic ways in which the Controller can communicate
with the Model (or the View).

First, the Controller and Model (and/or View) classes can be
combined into a single class, so the Controller object is also
the Model (and/or View) object. This is kind of cheating, but
a lot of simple example programs are implemented this way.

Second, the Controller object can hold a reference to the Model
object (or the View object). This is the standard way for any
two objects to communicate; they hold references to each other.


In EventExperiment versions 1 through 7, we show seven ways to give
the Controller object references to the Model and View objects. In
example EventExperiment_ver8.java we show how to combine all three
of the Model, View, and Controller into a single class (and hence a
single object).

In EventExperiment_ver1.java, the Controller holds references to
each of the Model and View objects. These references are passed to
the Controller object in its constructor call.

In EventExperiment_ver2.java, the Controller is a static nested class
in the program class and the program class has two static fields that
refer to the Model and the View. The Controller object no longer needs
explicit fields that refer to the Model and View objects since the
controller object has the two static fields in its scope.

In EventExperiment_ver3.java, the Controller is a nested class in
the program class and the program class has two (instance) fields
that refer to the Model and the View. The Controller object does
not need explicit fields that refer to the Model and View objects
since the controller object has the two fields in its scope.

In EventExperiment_ver4.java, the Controller is a local nested class
in the program class's constructor and the constructor has two local
variables that refer to the Model and the View. The controller object
has those two local variables within its scope.

In EventExperiment_ver5.java, the Controller is an anonymous local
nested class in the program class's constructor and the constructor
has two local variables that refer to the Model and the View. The
controller object has those two local variables within its scope.

EventExperiment_ver6.java is like EventExperiment_ver5.java and we
make the View into an anonymous local nested class in the program
class's constructor. The View object no longer needs an explicit
reference to the Model object since the constructor's local variables
are within the scope of the View object.

EventExperiment_ver7.java is like EventExperiment_ver6.java and
we make the Model into a local nested class in the program class's
constructor.

EventExperiment_ver8.java is like EventExperiment_ver6.java but
the controller is written as a lambda expression in the program
class's constructor. The controller has the Model and View
objects within its scope.

In EventExperiment_ver9.java, all three of the Model, View, and
Controller combined into the EventExperiment_ver9 class and a
single instance of that class is used to run the program.


An interesting thing to note in these examples is that as the
definition of the button's event handler class changes from a
   private class         in EventExperiment_ver1.java, to a
   static nested class   in EventExperiment_ver2.java, to a
   nested class          in EventExperiment_ver3.java, to a
   local class           in EventExperiment_ver4.java, to a
   anonymous local class in EventExperiment_ver5.java, to a
   lambda expression     in EventExperiment_ver8.java,
the definition of the event handler's actionPerformed() method
keeps moving closer to the location in the code where that method
is needed, the place where the method is registered as the button's
event handler. This is one of the design goals of the Java language
(and of most modern languages). To be able to define methods locally,
where they are needed.

For example, in an older language like C, no function can be defined
inside of a block of code. All functions must be defined at the "top
level" (the outer most level of indentation). So no function in C can
be defined locally, just where it is needed.

While Java does let us define methods locally, its syntax is not as
elegant and compact as most functional programming languages like
Haskell, ML, F#, Scheme, or Clojure.


The example EventExperiment2_ver1.java is similar to EventExperiment_ver1
but it has two fields in the Model and two pieces to the Controller (one
button for each field in the Model). And EventExperiment2_ver3 is similar
to EventExperiment_ver9, in that they both combine all the needed object
responsibilities into a single object. As an exercise, rewrite the program
EventExperiment2_ver1.java by implementing the button event handlers as
static nested classes, nested classes, local classes, and anonymous classes.


https://math.hws.edu/javanotes-swing/c5/s8.html#OOP.8.3
https://math.hws.edu/javanotes-swing/c6/s3.html#GUI1.4.5

https://docs.oracle.com/javase/tutorial/uiswing/events/generalrules.html

https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
https://docs.oracle.com/javase/tutorial/java/javaOO/localclasses.html
https://docs.oracle.com/javase/tutorial/java/javaOO/anonymousclasses.html
https://docs.oracle.com/javase/tutorial/java/javaOO/whentouse.html
