Great book written by Kathy Sierra and Bert Bates.
I wanted to share few important quotations found from the seventh chapter.
1) The equals() Contract
Pulled straight from the Java docs, the equals() contract says
It is reflexive. For any reference value x, x.equals(x) should return true.
It is symmetric. For any reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
It is transitive. For any reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) must return true.
It is consistent. For any reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the object is modified.
For any non-null reference value x, x.equals(null) should return false.
2) A hashCode() that returns the same value for all instances whether they're equal or not is still a legal—even appropriate—hashCode() method! For example,
public int hashCode() { return 1492; }
This hashCode() method is horribly inefficient, remember, because it makes all objects land in the same bucket, but even so, the object can still be found as the collection cranks through the one and only bucket—using equals()—trying desperately to finally, painstakingly, locate the correct object. In other words, the hashcode was really no help at all in speeding up the search, even though improving search speed is hashcode's intended purpose!
3) The hashCode() Contract
a) Whenever it is invoked on the same object more than once during an execution of a Java application, the hashcode() method must consistently return the same integer, provided no information used in equals() comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
b) If two objects are equal according to the equals(object) method, then calling the hashCode() method on each of the two objects must produce the same integer result.
c) It is NOT required that if two objects are unequal according to the equals(Java.lang.Object) method, then calling the hashCode() method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.
4) Transient variables can really mess with your equals() and hashcode() implementations. Keep variables non-transient or, if they must be marked transient, don't use then to determine hashcodes or equality.
5) A Vector is basically the same as an ArrayList, but Vector methods are synchronized for thread safety.
6) A Set does not allow for duplicates.A HashSet is an unsorted, unordered Set.
7) Hashtable is the synchronized counterpart to HashMap.Another difference, though, is that while HashMap lets you have null values as well as one null key, a Hashtable doesn't let you have anything that's null.
8) Below table gives more details of the collection classes
| Class | Map | Set | List | Ordered | Sorted |
|---|---|---|---|---|---|
| HashMap | x | No | No | ||
| HashTable | x | No | No | ||
| TreeMap | x | Sorted | By natural order or custom comparison rules | ||
| LinkedHashMap | x | By insertion order or last access order | No | ||
| HashSet | x | No | No | ||
| TreeSet | x | Sorted | By natural order or custom comparison rules | ||
| LinkedHashSet | x | By insertion order | No | ||
| ArrayList | x | By index | No | ||
| Vector | x | By index | No | ||
| LinkedList | x | By index | No | ||
| PriorityQueue | x | Sorted | By to-do order |
9) Unlike basic queue structures that are first-in, first-out by default, a PriorityQueue orders its elements using a user-defined priority. The priority can be as simple as natural ordering (in which, for instance, an entry of 1 would be a higher priority than an entry of 2). In addition, a PriorityQueue can be ordered using a Comparator, which lets you define any ordering you want. Queues have a few methods not found in other collection interfaces: peek(), poll(), and offer().
10) List, which is the wildcard without the keywords extends or super, simply means "any type." So that means any type of List can be assigned to the argument. That could be a List of
11) We cannot use wildcard notation in the object creation.
12) When using a wildcard like List, the collection can be accessed but not modified.
13) When using a wildcard like List, any generic type can be assigned to the reference, but for access only, no modifications.
No comments:
Post a Comment