| << Chapter < Page | Chapter >> Page > |
Framea.java
package view;
/*** A direct concrete subclass of AFrame with its own initializaion code.
*/public class FrameA extends AFrame {
/*** Calls AFrame constructor, which calls the cocnrete inititialize() method
* of this FrameA. This is done dynamically at run-time when a FrameA* object is instantiated.
*/public FrameA(String title) {
super(title);}
/*** The superclass initialize() method is abstract: don't call it here!
* Just write application specific initialization code for this FrameA here.*/
protected void initialize() {// Application specific intialization code for FrameA goes here...
}}
Frameab.java
package view;
/*** A second level descendant class of AFrame
* that initializes itself by calling the* initialize() method of its direct superclass
* in addition to its own initialization code.*/
public class FrameAB extends FrameA {/**
* Calls the superclass constructor, FrameA,* which in turns calls its superclass constructor,
* AFrame, which first calls its superclass* constructor, JFrame, and then executes the
* initialize() method of this FrameAB.*/
public FrameAB(String title) {super(title);
}/**
* At run-time, when the constructor AFrame is* executed, it calls this FrameAB initialize()
* method and NOT the initialize() method of the* superclass FrameA. In order to reuse the
* initialization code for FrameA, we must make* the super call to initialize().
*/protected void initialize() {
// Call initialize() of FrameA:super.initialize();
/*** Additional application specific intialization
* code for FrameAB goes here...*/
}}
Frameac.java
package view;
/*** A second level descendant class of AFrame
* that bypasses the initialize() method of* its direct superclass in its own
* initialization code. Since proper* initialization of a subclass depends on
* proper initialization of the super class,* bypassing the initialization code of the
* superclass is a BAD idea!*/
public class FrameAC extends FrameA {/**
* Calls the superclass constructor, FrameA,* which in turns calls its superclass constructor,
* AFrame, which first calls its superclass* constructor, JFrame, and then executes the
* initialize() method of this FrameAC.*/
public FrameAC(String title) {super(title);
}/**
* At run-time, when the constructor AFrame is* executed, it calls this initialize() method and
* NOT the initialize() method of the superclass* FrameA. This method does not call the super
* class's initialize() method. As a result, the* initialization done in the superclass is
* bypassed completely. This is a BAD idea!*/
protected void initialize() {/**
* Application specific intialization code for* FrameAC goes here...
*/}
}
Frame0App.java represents one of the simplest GUI application in Java: it simply pops open an
Frame0 object.
Frame0 is subclass of
AFrame that does nothing in its concrete
initialize() method.
Frame1.java is available in the source code
archive file .To display other GUI components on a
JFrame , we first need to get the content pane of the
JFrame and then add the desired GUI components to this content pane.
If we want to arrange the added GUI components in certain ways, we need to add an appropriate "
layout manager " to the
JFrame . The task of laying out the GUI component inside of a container GUI component is specified by an interface called
LayoutManager . In Frame1, we add the
FlowLayout that arranges all GUI components in a linear fashion. If we do not add any layout manager to the
JFrame , it has no layout manager and does a very bad job of arranging GUI components inside of it. As an exercise, comment out the code to add the
FlowLayout to Frame1 and see what happens!
JFrame is not responsible for arranging the GUI components that it contains. Instead it delegates such a task to its layout manager,
LayoutManager . There are many concrete layout managers:
FlowLayout ,
BorderLayout ,
GridLayout , etc. that arrange the internal components differently. There are said to be different strategies for layout. The interaction between
JFrame and its layout manager is said to follow the
Strategy Pattern .
The strategy pattern is powerful and important design pattern. It is based on that principle of delegation that we have been applying to model many of the problems so far. It is a mean to delineate the invariant behavior of the context (e.g.
JFrame ) and the variant behaviors of a union of algorithms to perform certain common abstract task (e.g.
LayoutManager ). We shall see more applications of the strategy design pattern in future lessons.
At this point the only the buttons in the
Frame1 example do not perform any task besides "blinking" when they are clicked upon. The example in the next lecture will show how to associate an action to the click event.
Notification Switch
Would you like to follow the 'Principles of object-oriented programming' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|