Mysql, Java, Jsp, Servlet, Tomcat, Ssh, Shared Web Hosting Blog

Chapter 9 Object-Oriented Programming 519 1. If a class A is a subclass of class B, then A extends B in the class declaration and calls the constructor of B. For example, class Elevator is a subclass of abstract superclass Location, so the class declaration should read public class Elevator extends Location { public Elevator { super(); } … 2. If class B is an abstract class and class Ais a subclass of class B, then class Amust override the abstract methods of class B (if class A is to be a concrete class). For example, class Location contains abstract methods getLocationName, getButton and getDoor, so class Elevator must override these methods (note that getButton returns the Elevator s Button object, and getDoor returns the Elevator s Door object Elevator contains associations with both objects, according to the class diagram of Fig. 9.38). public class Elevator extends Location { // class attributes private boolean moving; private boolean summoned; private Location currentFloor; private Location destinationFloor; private int capacity = 1; private int travelTime = 5; // class objects private Button elevatorButton; private Door elevatorDoor; private Bell bell; // class constructor public Elevator() { super(); } // class methods public void ride() {} public void requestElevator() {} public void enterElevator() {} public void exitElevator() {} public void departElevator() {} // method overriding getLocationName public String getLocationName() { return “elevator”; } Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

518 Object-Oriented Programming Chapter 9 Person -ID : Integer -moving : Boolean = true -location : Location + doorOpened( ) : void ElevatorShaft Bell ElevatorModel - numberPeople : Integer = 0 + ringBell( ) : void Location # locationName : String + getLocationName( ) : String + getButton( ) : Button + getDoor( ) : Door Light -lightOn : Boolean = false + turnOnLight( ) : void + turnOffLight( ) : void + addPerson( ) : void Button - pressed : Boolean = false + resetButton( ) : void + pressButton( ) : void Door -open : Boolean = false + openDoor( ) : void + closeDoor( ) : void Floor - capacity : Integer = 1 # locationName : String + getLocationName( ) : String + getButton( ) : Button + getDoor( ) : Door Elevator -moving : Boolean = false - summoned:Boolean = false -currentFloor : Location - destinationFloor : Location -capacity : Integer = 1 - travelTime : Integer = 5 # locationName : String + ride( ) : void + requestElevator( ) : void + enterElevator( ) : void + exitElevator( ) : void + departElevator( ) : void + getLocationName( ) : String + getButton( ) : Button + getDoor( ) : Door Fig. 9.3939 Class diagram with attributes and operations (incorporating Fig. inheritance). Class Elevatornow contains two Locationobjects, called currentFloorand destinationFloor, replacing the integer values we used previously to describe the Floors. Lastly, Person contains a Location object named location, which indicates whether Personis on a Flooror in the Elevator. Implementation: Forward Engineering (Incorporating Inheritance) Thinking About Objects Section 8.17 used the UML to express the Java class structure for our simulation. We continue our implementation while incorporating inheritance, using class Elevatoras an example. For each class in the class diagram of Fig. 9.38, Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 517 Creates Light ElevatorModel Floor ElevatorShaft Bell Person Elevator Location # locationName : String + getLocationName( ) : String + getButton( ) : Button + getDoor( ) : Door Button - pressed : Boolean = false + resetButton( ) : void + pressButton( ) : void Connects Presses 2 2 2 21 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0..* 1 1 1 1 2 Signals to move Resets ResetsCloses Occupies Signals arrival Turns on/off Rings Door -open : Boolean = false + openDoor( ) : void + closeDoor( ) : void 2 1 Opens Fig. 9.3838 Class diagram of our simulator (incorporating inheritance). Fig. We have allowed a Person, occupying a Location, to interact with several of the objects in the simulator. For example, a Personcan press a Buttonor be informed when a Dooropens from that Person s specific Location. In addition, because a Person may occupy only one Location at a time, that Person may interact with only the objects known to that Location a Person will never perform an illegal action, such as pressing the first Floor s Buttonwhile riding the Elevator. We presented the class attributes and operations with access modifiers in Fig. 8.13. Now, we present a modified diagram incorporating inheritance in Fig. 9.39. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

516 Object-Oriented Programming Chapter 9 Location # locationName : String + getLocationName( ) : String + getButton( ) : Button + getDoor( ) : Door Floor -capacity : Integer = 1 # locationName : String + getLocationName( ) : String + getButton( ) : Button + getDoor( ) : Door Elevator - moving : Boolean = false -summoned:Boolean = false -currentFloor : Integer - destinationFloor : Integer -capacity : Integer = 1 - travelTime : Integer = 5 # locationName : String + ride( ) : void + requestElevator( ) : void + enterElevator( ) : void + exitElevator( ) : void + departElevator( ) : void + getLocationName( ) : String + getButton( ) : Button + getDoor( ) : Door Fig. 9.37 Generalization diagram of superclass Locationand subclasses Elevatorand Floor. Classes Floorand Elevatoroverride methods getButtonand getDoorfrom their superclass Location. In Fig. 9.37, these methods are italicized in class Location, indicating that they are abstract methods. However, the methods in the subclasses are not italicized these methods became concrete methods by overriding the abstract methods. Class Personnow contains a Locationobject representing whether the Personis on the first or second Floor or inside the Elevator. We remove the association between Personand Elevatorand the association between Personand Floorfrom the class diagram, because the Locationobject acts as both the Elevatorand Floorreference for the Person. A Personsets its Locationobject to reference the Elevatorwhen that Personenters the Elevator. A Personsets its Locationobject to reference a Floor when the Person is on that Floor. Lastly, we assign class Elevator two Locationobjects to represent the Elevator s reference to the current Floorand destination Floor(we originally used integers to describe these references). Figure 9.38 provides an updated class diagram of our model by incorporating inheritance and eliminating classes FloorButton, ElevatorButton, FloorDoorand ElevatorDoor. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 515 FloorDoor -open : Boolean = false + openDoor( ) : void + closeDoor( ) : void ElevatorDoor -open : Boolean = false + openDoor( ) : void + closeDoor( ) : void Fig. 9.3636 Attributes and operations of classes FloorDoorand Fig. ElevatorDoor. In Section 4.14, we encountered the problem of representing the location of the Person on what Flooris the Personlocated when riding in the Elevator? Using inheritance, we may now model a solution. Both the Elevatorand the two Floors are locations at which the Personexists in the simulator. In other words, the Elevatorand the Floors are types of locations. Therefore, classes Elevator and Floor should inherit from an abstract superclass called Location. We declare class Location as abstract, because, for the purposes of our simulation, a location is too generic a term to define a real object. The UML requires that we place abstract class names (and abstract methods) in italics. Superclass Location contains the protected attribute locationName, which contains a Stringvalue of “firstFloor”, “secondFloor”or “elevator”. Therefore, only classes Elevator and Floor have access to locationName. In addition, we include the publicmethod getLocationNameto return the name of the location. We search for more similarities between classes Floorand Elevator. First of all, according to the class diagram of Fig. 3.23, Elevator contains a reference to both a Button and a Door the ElevatorButton (the Elevator s Button) and the ElevatorDoor (the Elevator s Door). Class Floor, through its association with class ElevatorShaft (class ElevatorShaft connects class Floor), also contains a reference to a Buttonand a Door the FloorButton(that Floor s Button) and the FloorDoor(that Floor s Door). Therefore, in our simulation, the Location class, which is the superclass of classes Elevator and Floor, will contain public methods getButtonand getDoor, which return a Buttonor Doorreference, respectively. Class Flooroverrides these methods to return the Buttonand Doorreferences of that Floor, and class Elevatoroverrides these methods to return the Button and Doorreferences of the Elevator. In other words, class Floorand Elevatorexhibit distinct behavior from each other but share attribute locationNameand methods get- Buttonand getDoor therefore, we may use inheritance for these classes. The UML offers a relationship called a generalization to model inheritance. Figure 9.35 is the generalization diagram of superclass Location and subclasses Elevatorand Floor. The empty-head arrows specify that classes Elevator and Floor inherit from class Location. Note that attribute locationNamehas an access modifier that we have not yet seen the pound sign (#), indicating that locationNameis a protected member, so Location subclasses may access this attribute. Note that classes Floorand Elevatorcontain additional attributes and methods that further distinguish these classes. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

514 Object-Oriented Programming Chapter 9 ElevatorButton - pressed : Boolean = false + resetButton( ) : void + pressButton( ) : void FloorButton - pressed : Boolean = false + resetButton( ) : void + pressButton( ) : void Fig. 9.3535 Attributes and operations of classes FloorButtonand Fig. ElevatorButton. We must now examine whether these objects exhibit distinct behavior. If the ElevatorButtonand FloorButtonobjects have the same behavior, then we cannot justify using two separate classes to instantiate these objects. However, if these objects have distinct behaviors, we can place the common attributes and operations in a superclass Button; then ElevatorButton and FloorButton inherit both the attributes and operations of Button. We have been treating the FloorButtonas if it behaves differently from the ElevatorButton the FloorButtonrequests the Elevatorto move to the Floorof the request, and the ElevatorButton signals the Elevator to move to the opposite Floor. Under closer scrutiny, we notice that both the FloorButton and the ElevatorButton signal the Elevator to move to a Floor, and the Elevator decides whether to move. The Elevator will sometimes move in response to a signal from the FloorButton, and the Elevator will always move in response to a signal from the ElevatorButton however, neither the FloorButtonnor the ElevatorButton decides for the Elevatorthat the Elevatormust move to the other Floor. We conclude that both FloorButton and ElevatorButton have the same behavior both signal the Elevator to move so we combine (not inherit) classes into one Button class and discard class FloorButtonand ElevatorButtonfrom our case study. We turn our attention to classes ElevatorDoor and FloorDoor. Figure 9.36 shows the attributes and operations of classes ElevatorDoorand FloorDoor these two classes are structurally similar to each other as well, because both classes possess the attribute openand the two operations openDoorand closeDoor. In addition, both the ElevatorDoorand FloorDoorhave the same behavior they inform a Personthat a door in the simulation has opened. The Personthen decides either to enter or exit the Elevator, depending on which door opened. In other words, neither the Elevator- Door nor the FloorDoor decides for the Person that the Person must enter or exit the Elevator. We combine both ElevatorDoor and FloorDoor into one Door class and eliminate classes ElevatorDoorand FloorDoorfrom our case study.2 2. As we continue to discuss inheritance throughout this section, we refer to the class diagram of Fig. 3.23 to determine similarities among objects. However, this diagram contains classes FloorButtonand ElevatorButton, which we have eliminated recently from the case study. Therefore, during our discussion of inheritance, when we mention the FloorButton, we refer to that Floor s Buttonobject, and when we mention the ElevatorButton, we refer to the Elevator s Buttonobject. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 513 3. To access the outer class s this reference, use OuterClassName.this. 4. The outer class is responsible for creating objects of its inner classes. To create an object of another class s inner class, first create an object of the outer class and assign it to a reference (we will call it ref). Then use a statement of the following form to create an inner class object: OuterClassName.InnerClassName innerRef = ref.new InnerClassName(); 5. An inner class can be declared static. A static inner class does not require an object of its outer class to be defined (whereas a nonstatic inner class does). A static inner class does not have access to the outer class s nonstatic members. 9.22 Type-Wrapper Classes for Primitive Types Each of the primitive types has a type-wrapper class. These classes are called Character, Byte, Short, Integer, Long, Float, Double and Boolean. Each type- wrapper class enables you to manipulate primitive types as objects of class Object. Therefore, values of the primitive data types can be processed polymorphically if they are maintained as objects of the type-wrapper classes. Many of the classes we will develop or reuse manipulate and share Objects. These classes cannot polymorphically manipulate variables of primitive types, but they can polymorphically manipulate objects of the type- wrapper classes, because every class ultimately is derived from class Object. Each of the numeric classes Byte, Short, Integer, Long, Float and Double inherits from class Number. Each of the type wrappers is declared final, so their methods are implicitly final and may not be overridden. Note that many of the methods that process the primitive data types are defined as staticmethods of the type- wrapper classes. If you need to manipulate a primitive value in your program, first refer to the documentation for the type-wrapper classes the method you need might already be defined. We will use the type-wrapper classes polymorphically in our study of data structures in Chapters 22 and 23. 9.23 (Optional Case Study) Thinking About Objects: Incorporating Inheritance into the Elevator Simulation We now examine our elevator simulator design to see whether it might benefit from inheritance. In previous chapters, we have been treating ElevatorButton and FloorButton as separate classes. These classes, however, have much in common both have attribute pressed and behaviors pressButton and resetButton. To apply inheritance, we first look for commonality between these classes. We extract this commonality, place it into superclass Button, then derive subclasses ElevatorButton and Floor- Button from Button. Let us now examine the similarities between classes ElevatorButton and FloorButton. Figure 9.35 shows the attributes and operations of each class. Both classes have their attribute (pressed) and operations (pressButton and reset- Button) in common. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

512 Object-Oriented Programming Chapter 9 clicking the window s close box (labeled in the first screen capture). Method addWindowListener registers a window event listener. The argument to addWindowListener must be a reference to an object that is a WindowListener (package java.awt.event) (i.e., any object of a class that implements WindowListener). However, there are seven different methods that must be defined in every class that implements WindowListener and we only need one in this example windowClosing. For event handling interfaces with more than one method, Java provides a corresponding class (called an adapter class) that already implements all the methods in the interface for you. All you need to do is extend the adapter class and override the methods you require in your program. Common Programming Error 9.10 Extending an adapter class and misspelling the name of the method you are overriding is a logic error. Lines 121 129 use special Java syntax to define an anonymous inner class and create one object of that class that is passed as the argument to addWindowListener. Line 118 uses operator new to create an object. The syntax WindowAdapter() begins the definition of an anonymous inner class that extends class WindowAdapter. This is similar to beginning a class definition with public class MyHandler extends WindowAdapter { The parentheses after WindowAdapter indicate a call to the default constructor of the anonymous inner class. Class WindowAdapter implements interface WindowListener, so every WindowAdapter object is a WindowListener the exact type required for the argument to addWindowListener. The opening left brace ({) at the end of line 121 and the closing right brace (}) at line 129 define the body of the class. Lines 124 127 override the windowClosing method of WindowAdapter that is called when the user clicks the window s close box. In this example, windowClosing terminates the application. In the last two examples, we have seen that inner classes can be used to create event handlers and that separate anonymous inner classes can be defined to handle events individually for each GUI component. In Chapter 12 and Chapter 13, we revisit this concept as we discuss the event handling mechanism in detail. 9.21 Notes on Inner Class Definitions This section presents several notes of interest to programmers regarding the definition and use of inner classes. 1. Compiling a class that contains inner classes results in a separate .class file for every class. Inner classes with names have the file name OuterClassName$Inner- ClassName.class. Anonymous inner classes have the file name OuterClass- Name$#.class, where # starts at 1 and is incremented for each anonymous inner class encountered during compilation. 2. Inner classes with class names can be defined as public, protected, package access or privateand are subject to the same usage restrictions as other members of a class. Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

Chapter 9 Object-Oriented Programming 511 Fig. 9.34 Demonstrating anonymous inner classes (part 4 of 4). Each of the three JTextFields that generate events in this program has a similar anonymous inner class to handle its events, so we discuss only the anonymous inner class for hourField here. Lines 33 48 are a call to hourField s addActionListener method. The argument to this method must be an object that is an ActionListener(i.e., any object of a class that implements ActionListener). Lines 36 46 use special Java syntax to define an anonymous inner class and create one object of that class that is passed as the argument to addActionListener. Line 36 uses operator newto create an object. The syntax ActionListener()begins the definition of an anonymous inner class that implements interface ActionListener. This is similar to beginning a class definition with public class MyHandler implements ActionListener { The parentheses after ActionListener indicate a call to the default constructor of the anonymous inner class. The opening left brace ({) at the end of line 36 and the closing right brace (}) at line 46 define the body of the class. Lines 38 44 define the actionPerformedmethod that is required in any class that implements ActionListener. Method actionPerformedis called when the user presses Enter while typing in hourField. Software Engineering Observation 9.34 When an anonymous inner class implements an interface, the class must define every method in the interface. Method maincreates one instance of class TimeTestWindow(line 115), sizes the window (line 133) and displays the window (line 134). Windows generate a variety of events that are discussed in Chapter 13. For this example we discuss the one event generated when the user clicks the window s close box a window closing event. Lines 118 131 enable the user to terminate the application by Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01

510 Object-Oriented Programming Chapter 9 105 // display time in displayField 106 public void displayTime() 107 { 108 displayField.setText( “The time is: ” + time ); 109 } 110 111 // create TimeTestWindow, register for its window events 112 // and display it to begin application’s execution 113 public static void main( String args[] ) 114 { 115 TimeTestWindow window = new TimeTestWindow(); 116 117 // register listener for windowClosing event 118 window.addWindowListener( 119 120 // anonymous inner class for windowClosing event 121 new WindowAdapter() { 122 123 // terminate application when user closes window 124 public void windowClosing( WindowEvent event ) 125 { 126 System.exit( 0 ); 127 } 128 129 } // end anonymous inner class 130 131 ); // end call to addWindowListener 132 133 window.setSize( 400, 120 ); 134 window.setVisible( true ); 135 } 136 137 } // end class TimeTestWindow Close box Fig. 9.34 Demonstrating anonymous inner classes (part 3 of 4). Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/7/01