ITEC 120 2010fall ibarland

home—info—lects—labs—exams—hws
tutor/PIs—Object120 + its docs—java.lang docs—java.util docs

lab08b
finishing equality

As a class, we will take Robots.java and explain why (a) the tests currently fail, and (b) Converting a Robot to a String looks odd.

toString is actually built in to Java, and is pre-defined for all Objects. However, it doesn't print objects very nicely! It just prints the name of the class, followed by the (hexadecimal) memory address where the object is stored. (That's the arrow itself -- the reference.)

We will improve toString this “overriding” the built-in version with our own toString method for Robots. Note that we must declare it public.

We have already discussed how we might want two versions of equals: one (equals) which checks if two objects have all the same fields, and another (==) which just checks if the two references are the same.
But something isn't quite right; our Robot tests fail! (new Robot( "4-F", "pen", true, true)).equals( new Robot( "4-F", "pen", true, true) ) returns false?!

The truth is: equals is also built-in to Java and defined for all Objects. However, just like the built-in toString isn't very helpful, neither is the built-in equals: it does the exact same thing that == does! We must override it with our own specific version. Task: Write an object-oriented version of equals for Robots. After doing so, the test cases should work again.

(Okay, to be fair: Sometimes == is the behavior you want for objects. And since equals is used in already-written future-compatible code, the default isn't unreasonable. Still, I'd have personally preferred a default version where equals compared each field rather than just compared references.)

Rule of thumb: When you write a class, you probably want to use the default, built-in equals whenever your program will create only one new instance corresponding to objects in the real world (e.g. Pizzas or Students).

Rule of thumb: When you write a class, you probably want to use the default, built-in equals whenever you have methods which update (mutate) fields.
(This often goes hand-in-hand with the previous rule.)

Rule of thumb: When you write a class, you should override equals if you can't conceive of two instances having the same fields, but somehow being considered different. E.g., String or RaceResult.

Testing tip: For testing, we usually want a “deep equals” that checks each field (comparing fields for deep equality themselves). However, this might conflict with the rules-of-thumb above. One solution is to write your own method deepEquals (separate from equals), and use that in your test methods. This works fine for a single class, but becomes more complicated if you have an object whose fields are other objects.

home—info—lects—labs—exams—hws
tutor/PIs—Object120 + its docs—java.lang docs—java.util docs

©2010, Ian Barland, Radford University Last modified 2010.Oct.21 (Thu)

Please mail any suggestions (incl. typos, broken links) to iba�rlandrad�ford.edu