Typecasts and Dynamic Dispatch. Dynamic dispatch

Transcription

1 Typecasts and Dynamic Dispatch Abstract Data Type (ADT) Abstraction Program Robustness Exceptions D0010E Lecture 8 Template Design Pattern Review: I/O Typecasts change the type of expressions as interpreted at compile-time. By writing (T) e we state that T should be the type of e at this point in the code where e is used. T must either be a supertype of (called an upcast) or conform with (called a downcast) the declared type of e. Easy explanation: Both types must lie on the same path connecting a leaf and the root (Object) in the inheritance tree. 1 2 Upcasts always works (Need not be explicit) An upcast Dynamic dispatch A Super Sub Super s1 (Super) new Sub (); Sub s2 = (Sub) s1; A downcast Needed to state that the type on the right-hand side conforms with the type on the left. H G F D C B J I L M N O Works at run-time because the type of the dynamic object referred to by s1 conforms with Sub. (In general: If not, there will be a run-time error.) Works at compile-time because the type of s1 is a supertype of Sub. Downcasts must be written in Java to have the programmer explicitly guarantee to 1. the compiler, and 2. fellow programmers, that the types indeed do conform. (Upcast; no need to be explicit here) E E x = new E(); x.f(); C x = new E(); x.f(); D x = new D(); x.f(); B x = new K(); x.f(); K P M x = new M(); x.f(); B x = new O(); ((L) x).f(); 3 (Downcast; N, M, and B also works at run-time but not P) 4

2 An Example to Try in Eclipse 1. Abstraction A B C D E F package l08.dynamicdispatch; public class Main { public static void main(string[] args) { A x = new E(); ((C) x).f(); } } class A { void f() { System.out.println("A"); } } class B extends A { void f() { System.out.println("B"); } } class C extends B { void f() { System.out.println("C"); } } class D extends C { void f() { System.out.println("D"); } } class E extends D { void f() { System.out.println("E"); } } class F extends E { void f() { System.out.println("F"); } } We all have an ability to disregard unimportant details in favour of the important. We can focus our attention. Our perception of the World is much filtered, it seems. Our senses do this automatically for us. Although your eyes "see" everything in front of you, the brain "ignores" everything except for a few important details. We can also control this filtering, to some degree. We can train ourselves, learn. We can also, it seems, control not only what we disregard and perceive but also how. This is probably a factor that has helped us survive as a spieces. 5 6 Abstraction Abstraction and programming We apply abstraction whenever we name things and just use the names without giving all the details. Very practical This is also true in programming where languages provide means to abstract away from the computer. Early inventions such as variables and methods are, for instance, nothing but abstractions of computer memory (data and code). Abstraction in programming allows us to disregard details in how computers work and instead focus on the problems we like to solve. We build models of real-world entities, define operations that mimic possible actions in the real world, and express real-world interactions between entities in code. Object-oriented programming provides the (so far) best tools for doing this. In object-oriented programming a most useful abstraction is an abstract view on a class. 7 8

3 Needed to write large programs Two different views on a class The abstract view An external description. WHAT a class represents and WHAT its function is. Needed by someone who likes to use the class. Format: UML-diagrams Abstract data types The implementation view An internal description. HOW it works and HOW variables, methods etc are implemented. Needed by someone who likes to re-program the class. Format: Source code Any programmer that writes software that uses a class is a client, the software is client code, and the class is a supplier class. Usually the focus in plain programming courses 9 2. Abstract Data Types An abstract data type (ADT) is a triplet containing 1) a set of values, A well-defined domain. Ex: Time of day in terms of hours and minutes. 2) a set of operations on the values, and Ex: inchour() and incminute() that increases the hour and minute by one unit respectively. 3) a set of axioms. Truths about the operations and the set of values. Ex: The hour is always 0, 23, or in-between these two values. If the clock is one minute to a whole hour, incminute() results in the minute being reset to zero. An ADT is a mathematical object used to reason about programs. 10 ADT:s and Program Design The rigor by which ADT:s can be defined have proved extremely useful to programmers. An ADT captures the fundamental functionality of the program. They are theoretical representations and a basis for proving program properties. Object-oriented programming much amounts to identifying these ADT:s and how they are used, and to program them properly. Some Common (General) ADT:s Container, Deque, List, Map (also called Dictionary), Multimap, Multiset, Priority queue, Queue, Set, Stack, String, and Tree. These are good building blocks to start from. Many are included in Java s standard library. But a programmer most often need to come up with new, different and sometimes tailor-made, ADT:s

4 Design and implementation Design determines the software s architecture. (What task does the software perform?) ADT Associated Operations Class Diagram myclass + type var1 Class Specification domain & class invariant Code public class myclass {... } Implementation determines the software s code. (How does the software perform its task?) Data + type method() + void method2(parm) method2(parm) pre:... modifies:... post: The Object of Data Abstraction and Structure, David D. Riley Addison Wesley pub. Design Implementation 14 Software specification Implementing ADT:s in Java Often written in the source code as comments. Mimics the ADT. Contains A domain Provides an abstract view on the state. Need not exist in the implementation view() Used to express invariants and pre/post conditions. Most often Mathematical types, sets, sequences. Class invariants. Everything relevant that stays invariant through-out the life of a dynamic object of this class, pre- and postconditions for methods. As for an abstract view versus an implementation view, a specification separates WHAT from HOW. Ordinary classes could work fine but rather implement ADT:s either as abstract classes or interfaces. Then, the implementation can be provided in the form of a concrete class that extends the abstract class (or implements the interface). We can have many different classes implementing the same ADT One being a fast initial hack due to lack of time, another a bit slow but 100% correct, yet another very efficient but only believed to work, Flexibility a fourth implementation using a totally different approach, etc Even more importantly, if clients only program using the abstract class/the interface, any of our concrete classes can be used in the end 15 16

5 Queue q = new FIFO(); (for example) Also, FastQ or DebugQueue could be used here. X <<interface>> Queue +isempty() : boolean +size() : int... FIFO FastQ DebugQueue Because of the inheritance relation, FIFO, FastQ, and DebugQueue can all be used where a Queue can be used. Why ADT:s? Things that belong together are grouped together. Easier to change a program. Gives overview. Small, graspable ADT:s are easy to understand and work with. Enables simultaneous work on parts of programs. Could start with a simple implementation and change it independently of other parts. ==> Very good for cooperation Advice about ADT:s Its better with a large number of small ADT:s than a small number of large ones. Large ones are hard to overview and program correctly. When designing ADT:s abstract away details (hide them), be precise (well-written specifications, invariants and axioms), and design with the intend to re-use the ADT:s over and over again in the future. 19 In this example, operation1(), operation2(), are abstract, templatemethod is not. 3. Template Design Pattern templatemethod() is inherited as it is, while the operations are declared (made concrete). (The templatemethod() could also be shadowed, totally redefining it. This is a usual practice.) ( operation1(), operation2(), are used here only as an example) operation1(), operation2() could have different definitions here resulting in different behavior of the inherited templatemethod(). (Because of dynamic dispatch.) 20

6 4. Program robustness Good programs are robust. They handle unexpected errors and exceptional situations well during run-time. Traditionally, methods return error codes when they detect errors. Drawback: Callers have to check for errors, which results in massive amounts of extra code in methods. Java (and other modern languages) provides another kind of support for detecting, handling, and recovering from run-time errors: Exceptions. Exceptions An exception corresponds to a run-time error, for instance Attempted division by zero. Attempted read from a non-existent file. Attempted access to an array cell that does not exist (invalid index). etc It is represented by a dynamic object of the class Throwable. Rather: A subclass of Throwable Common Exceptions ArithmeticException A calculation gone wrong, like division with zero. ClassCastException Bad type cast. NullPointerException Attempted use of a reference variable that is null. IOException Errors that has to do with input and output to/from files, streams, the keyboard etc

7 Detection of Exceptions When an error is detected, an exception is thrown and normal program execution is interrupted. An immediate return through all methods that have been called is started. If a has called b, that has called c, that has called d, and an exception occurs in d, the sequence back is c- b- a. This stops as soon as a method that handles the exception is encountered or the main-method is reached (and the program halts). Most exceptions are thrown automatically when an error occurs. public class Main { public static void main(string[] args) { System.out.println("Before..."); Anders a = new Anders(); // line 4 System.out.println("... After."); } } class Anders { public Anders() { Bertil b = new Bertil(); // line 11 } } class Bertil { public Bertil() { int ludde = 12; ludde = ludde / 0; // line 18, division by 0 } } Before... Exception in thread "main" java.lang.arithmeticexception: / by zero at Bertil.<init>(Main.java:18) at Anders.<init>(Main.java:11) at Main.main(Main.java:4) Explicit Exceptions Exceptions can also be thrown explicitly: public class Main { public static void main(string[] args) { System.out.println("Before..."); Anders a = new Anders(); // line 4 System.out.println("... After."); } } class Anders { public Anders() { Bertil b = new Bertil(); // line 11 } } class Bertil { public Bertil() { int ludde = 12; ludde = ludde / 0; // line 18, division by 0 } } A traceback (stack trace) throw new ExceptionKind( Error msg ); throw new ExceptionKind(); These exceptions are generated by the program itself

8 public class Main { public static void main(string[] args) { System.out.println("Before..."); Anders a = new Anders(); System.out.println("... After."); } } class Anders { public Anders() { Bertil b = new Bertil(); } } class Bertil { public Bertil() { throw new RuntimeException("Just joking"); } } Before... Exception in thread "main" java.lang.runtimeexception: Just joking at Bertil.<init>(Main.java:17) at Anders.<init>(Main.java:11) at Main.main(Main.java:4) public class Main { public static void main(string[] args) { System.out.println("Before..."); Anders a = new Anders(); System.out.println("... After."); } } class Anders { public Anders() { Bertil b = new Bertil(); } } class Bertil { public Bertil() { throw new RuntimeException("Just joking"); } } Uncaught Exceptions Caught Exceptions An uncaught exception is handled by the Java virtual machine and results in program termination. And a traceback as shown. Like the previous examples. Many errors like Out of memory or No such class should be uncaught. There is not much a program can do about such errors but to terminate. Many times it is, however, preferable to handle an error in the program. Should be done if it is easy to recover from the error. Some exceptions are also thrown deliberately to be handled by other parts of the program. Then, the program should catch [the thrown] exception. This is done in a try-catch statement

9 public class Main { public static void main(string[] args) { System.out.println("Before..."); Anders a = new Anders(); System.out.println("... After."); } } class Anders { public Anders() { try { Bertil b = new Bertil(); System.out.println( No error ); } catch (RuntimeException e) { System.out.println("Ohps An error occured."); } } } class Bertil { public Bertil() { throw new RuntimeException("Just joking"); } } 33 1) Note the absence of a line containing No error Since an exception was thrown we never reached the line where this should have been printed. 2) The error message (the traceback) is not printed since we handle the exception on our own. 3) The program terminates normally. without a stack trace. Result Before... Ohps An error occured.... After. public class Main { public static void main(string[] args) { System.out.println("Before..."); Anders a = new Anders(); System.out.println("... After."); } } class Anders { public Anders() { try { Bertil b = new Bertil(); System.out.println( No error ); } catch (RuntimeException e) { System.out.println("Ohps An error occured."); } } } class Bertil { public Bertil() { throw new RuntimeException("Just joking"); } } 34 Checked and Unchecked" Standard Exceptions Checked exceptions must either 1) be caught using try-catch in a method, or 2) be listed in a throws clause of any method that may throw (propagate) them public void doit() throws IOException { // code that could cause an IOException } leaving the exception handling to the caller. Unchecked exceptions need not be caught. If a client can reasonably be expected to recover from an exception, make it a checked exception. Example: IOException If a client cannot do anything to recover from the exception, make it an unchecked exception. Example: Division by zero, array index out of bounds. 35 Must be handled 36

10 5. Basic I/O in Java "I/O" means "Input and Output" and how a Java program communicates with storage devices and the outer world. System.out.println is one way. Chapter 10 in Eck and Pillay, Part 2 in the course compendium. Needed in lab 3. (Reading from text files in GraphIO.) Use the Scanner class in the package java.util() Read Ch. 10 (and use Google ) to learn how. 37 Scanner package l08.scanner; import java.io.*; import java.util.*; public class StdIOTest { public static void main(string arg[]) { boolean stop = false, first = true; Scanner scanner = new Scanner(System.in); while (stop) { try { if (first) { System.out.printf("Input an integer: "); first = false; } else { System.out.printf("Input another integer: "); } int int_val = scanner.nextint(); System.out.println("Thank you. You entered " + int_val + "\n"); } catch (InputMismatchException e) { System.out.println("That is not an integer. Program terminates."); stop = true; } } } } 38 Reading from a file package l08.scanner; import java.io.file; import java.io.filenotfoundexception; import java.util.scanner; public class FileRead { public static void main(string arg[]) { try { File file = new File("src/l08/scanner/FileRead.java"); Scanner scanner = new Scanner(file); while (scanner.hasnext()) { System.out.println("-->" + scanner.next() + "<--"); } scanner.close(); } catch (FileNotFoundException e) { System.out.println("Can't open file. Program terminates."); } } } 39