The Java Inheritance Hierarchy CSIS 3701: Advanced Object Oriented Programming

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 superclass public class Clock extends Object { Object NameListClock Employee Implicitly added SecondClock Salaried Manager Hourly InternConsultant

Object Class Defines variables and methods common to all Java classes –May be overridden in subclasses Object this member variable toString method clone method equals method … By default, compares based on memory location (like ==) String equals 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 JFrame contentPane member variable getContentPane() method setSize(width, height) method setVisible(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 type value: 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(); intInteger doubleDouble charChar booleanBoolean …… 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