the java inheritance hierarchy csis 3701: advanced object oriented programming
TRANSCRIPT
Object Class
• All Java classes part of single inheritance hierarchy
• “Root” superclass: Object class
Object
String
JComponent
…
Object Class
• Developer-created classes part of hierarchy– If no superclass defined, Object used as superclasspublic class Clock extends Object {
Object
NameList Clock
Employee
Implicitly added
SecondClock
Salaried
Manager
Hourly
Intern Consultant
Object Class
• Defines variables and methods common to all Java classes– May be overridden in subclasses
Objectthis member variabletoString methodclone methodequals method…
By default, compares based on memory location (like ==)
Stringequals method…
Overrides inherited definition to do character-based comparison
Visual Applications
• All visual applications must extend JFrame– Inherits ability to be drawn on screen as independent
window
JFramecontentPane member variablegetContentPane() methodsetSize(width, height) methodsetVisible(boolean) method…
Main…
Methods inherited and called by your application
JComponent Hierarchy
Defines x, y position, width and height
Defines state of “clickable” components
Defines components with editable text
Note that must look at documentation for all classes above in hierarchy for description of available methods
JComponent Hierarchy
• Can add new classes to the hierarchy– Must invoke superclass constructor, passing required
information– Must use inherited methods to change what/how
information displayed
• Example: JRotateLabel class– Extends JLabel to display one of a list of labels
JComponent Hierarchy
public class JRotateLabel extends JLabel {
private String[] labels;
private int which;
public JRotateLabel(String[] labs) {
super(l[0]);
labels = l;
which = 0;
}
public void rotate() {
which++;
if (which >= labels.length) {which = 0;}
setText(labels[which]);
}
Pass first label in list to JLabel constructor as initial label to display
Call JLabel setText method to change which label is displayed
Type Wrapper Classes
• Simple types not part of Java inheritance hierarchy
• “Type wrappers”:– Objects that store instances of simple types as
member variable
137 Instance of int simple typevalue:
Object that stores an int as member variable
Type Wrapper Classes
• Java has “wrapper” class for each simple type:
• Can use to store/retrieve simple values:
Integer i = new Integer(137);
int x = i.intValue();
int Integer
double Double
char Char
boolean Boolean
… …
Store 137 in `new Integer object i
Retrieve value stored in i as an integer
Exception Class Hierarchy
• Java defines two types of exception– Exception– RuntimeException
(which extends Exception)
• Most commonly used exceptions extend RuntimeException
Exception Class Hierarchy
• Subclasses of Exception must be handled– Any statement that might cause one of these
exceptions must be inside try/catch block
– Code will not compile otherwise
• Example: File commands might cause IOException
try { File f = new File(“stuff.txt”); }catch (IOException ex) { … }
Opening a file might cause IOExeception if file does not exist, etc.
Must be caught
Exception Class Hierarchy
• Theory vs. Practice– Theory: Any statement that might cause exception
should be in try/catch block
– Practice: Would need to put almost every statement in try/catch block
• Any use of object could cause NullPointerException, etc.
Exception Class Hierarchy
• Compromise:– Only require handling for exceptions that might affect
memory external to program• Files/Networking: IOException• Databases: SQLException• Client/Server: ServletException
– Problems that cannot be restricted to JVM
• Design note:– Your exception classes should extend RuntimeException
Exceptions and Polymorphism
• Can use superclasses to write code that handles any exception
try { int x = Integer.parseInt(“Fred”); } catch(Exception ex) { … }
• Problem: How should it be handled?– No longer have information on the type of problem
Also matches any subclass of Exception (such as NumberFormatException)due to polymorphism
Designing Exception Hierarchies
• Can create hierarchy of exceptions – Can be as informative as possible about problem
– User can still catch superclass if they don’t care
catch (ClockException ex) {…}
ClockException
ClockHourException
ClockMinuteException
ClockHourHighException
ClockHourLowException
ClockMinuteHighException
ClockMinuteLowException