What would be needed?
Consider a bit of redesign as well.
Here is the running applet
Any program with a GUI consists of three parts:
Before the use of GUI's (and OOP), programs pretty much were procedure-driven.
These days, programs are much more event-driven.
Discuss.
Examples using MVC (cars, Windows95)
Basically, the model is the guts of the application. The programs (classes) doing the "work".
The view is how we let users see things happening in the model and see what they can do to the model. The view of the model changes when something in the model changes.
The controller is the interface or link between the model and the view. It allows the user to do things in the model by using the buttons, etc, on the view. The controller gets events triggered from the view and applies the proper behavior (sends a message) to the model.
In good designs, the classes that implement these should be separate. Why?
In object-oriented programming, one needs to instantiate a class
in order to get a concrete instance.
In addition, it makes the links to the controller
Also, it creates the model so that it also exists (Remember,
nothing exists until instantiated)
The controller is the event handler once an event is triggered and
detected on the view.
Notice the = =
Where would I find the repaint() method?
Why doesn't it have an instance handle in front of the call?
OK, now notice
Since this class PlayBalloon implements ActionListener ,
a separate controller is not used.
implementing ActionListener means that it provides the
actionPerformed (ActionEvent) method.
This MVC program could also have looked like the following if it were
clearly separated into the three parts:
MVC for the Balloon Example
init() and the View
The init() method in an Applet initializes the view.
What is the difference between initialize and instantiate?
Specifically, it sets up the widgets (buttons, etc) by instantiating
them and adding them to the Panel (or Applet - Applet extends Panel)
How About the Controller?
and the repaint();. repaint() clears the graphics area and then calls paint(Graphics g)
which is in the Applet.
In this example, they are putting the controller and the view
together. The ActionListener is the Interface
that acts as the controller here.
And then in the applet we would take off the implements
ActionListener, take out the references to this in
the addActionListener(this);
and add my instance of the Interface instead:
See it all at this location.
And note that it works the same.
I should also comment about classes in the same file. Only one can
be declared public. If each were in separate .java files,
they can be public.
For those who feel comfortable with this, another example is at this location
Look at the package java.awt.event to see other Interfaces. The various components in the package java.awt each will specify what kind of Listener is necessary (methods will have addActionListener(ActionListener), or whatever the proper listener is).
We will talk about specific widgets and their accompanying Interfaces when we get to Chapter 9 on Event Processing, since then we will deal more fully with event-handling.