02/12/1411:03:53 111 CS 61B: Lecture 11 Wednesday, February 12, 2014Today’s reading: Sierra & Bates, pp. 95-109, 662.equals()========Every class has an equals() method. If you don’t define one explictly, youinherit Object.equals(), for which "r1.equals(r2)" returns the same booleanvalue as "r1 == r2", where r1 and r2 are references. However, many classesoverride equals() to compare the _content_ of two objects.Integer (in the java.lang library) is such a class; it stores one private int.Two distinct Integer objects are equals() if they contain the same int.In the following example, "i1 == i2" is false, but "i1.equals(i2)" is true."i2 == i3" and "i2.equals(i3)" are both true. --- ------- --- ------- --- i1 |.+--->| 7 | i2 |.+--->| 7 |<---+.| i3 --- ------- --- ------- ---IMPORTANT: r1.equals(r2) throws a run-time exception if r1 is null.There are at least four different degrees of equality.(1) Reference equality, ==. (The default inherited from the Object class.)(2) Shallow structural equality: two objects are "equals" if all their fields are ==. For example, two SLists whose "size" fields are equal and whose "head" fields point to the same SListNode.(3) Deep structural equality: two objects are "equals" if all their fields are "equals". For example, two SLists that represent the same sequence of items (though the SListNodes may be different).(4) Logical equality. Two examples: (a) Two "Set" objects are "equals" if they contain the same elements, even if the underlying lists store the elements in different orders. (b) The Fractions 1/3 and 2/6 are "equals", even though their numerators and denominators are all different.The equals() method for a particular class may test any of these four levels ofequality, depending on what seems appropriate. Let’s write an equals() methodfor SLists that tests for deep structural equality. The following methodreturns true only if the two lists represent identical sequences of items. public class SList { public boolean equals(Object other) { if (!(other instanceof SList)) { // Reject non-SLists. return false; } SList o = (SList) other; if (size != o.size) { return false; } SListNode n1 = head; SListNode n2 = o.head; while (n1 != null) { if (!n1.item.equals(n2.item)) { // Deep equality of the items. return false; } n1 = n1.next; n2 = n2.next; } return true; } }Note that this implementation may fail if the SList invariants have beencorrupted. (A wrong "size" field or a loop in an SList can make it fail.)IMPORTANT: Overriding DOESN’T WORK if we change the signature of the originalmethod, even just to change a parameter to a subclass. In the Object class,the signature is equals(Object), so in the code above, we must declare "other"to be an Object too. If we declare "other" to be an SList, the equals() methodwill compile but it will NOT override. That means the code Object s = new SList(); s.equals(s);will call Object.equals(), not SList.equals(). Dynamic method lookup won’tcare that s is an SList, because the equals() method above is not eligible tooverride Object.equals().Therefore, if you want to override a method, make sure the signature is EXACTLYthe same."for each" LOOPS================Java has a "for each" loop for iterating through the elements of an array. int[] array = {7, 12, 3, 8, 4, 9}; for (int i : array) { System.out.print(i + " "); }Note that i is _not_ iterating from 0 to 5; it’s taking on the value of eacharray element in turn. You can iterate over arrays of any type this way. String concat = ""; for (String s : stringArray) { concat = concat + s; }For some reason, the type declaration _must_ be in the "for" statement. Thecompiler barfs if you try int i; for (i : array) { ... }02/12/1411:03:53 211TESTING=======Complex software, like Project 1, is easier to debug if you write lots of testcode. We’ll consider three types of testing:(1) Modular testing: testing each method and each class separately.(2) Integration testing: testing a set of methods/classes together.(3) Result verification: testing results for correctness, and testing data structures to ensure they still satisfy their invariants.(1) Modular Testing--------------------When you write a program and it fails, it can be quite difficult to determinewhich part of the code is responsible. Even experienced programmers oftenguess wrong. It’s wise to test every method you write individually.There are two types of test code for modular testing: test drivers and stubs.(a) Test drivers are methods that call the code being tested, then check theresults. In Lab 3 and Homework 3, you’ve seen test drivers in the SList classthat check that your code is doing the right thing.Both public and private methods should be tested. Hence, a test driver usuallyneeds to be inside the class it tests. In a class intended for use by otherclasses, the obvious place to put a test driver is in the main() method, as wedid in Lab 3 and Homework 3. However, if a class is the entry point for theprogram, you can’t put your test driver in main(). Instead, put it in a methodwith a name like testDriver(), and then write _another_ class whose main()method calls your test driver.(b) Stubs are small bits of code that are _called_ by the code being tested.They are often quite short. They serve three purposes.(i) If you write a method that calls other methods that haven’t yet been implemented, you can write simple stubs that fake the missing methods.(ii) Suppose you are having difficulty determining whether a bug lies in a calling method, or a method it calls. You can temporarily replace the callee with a stub that returns controlled results to the caller, so you can see if the caller is responsible for the problem.(iii)Stubs allow you to create repeatable test cases that might not arise often in practice. For instance, suppose a subroutine fetches and returns input from an airline database, and your code calls this subroutine. You might want to test whether your code operates correctly when ten airplanes depart at the same time. Such an event might be rare in practice, but you can replace the
View Full Document
Unlocking...