Ejp 01
•Descargar como PPSX, PDF•
0 recomendaciones•483 vistas
Presentation on "Effective Java" Book's chapter-03. Basically I covered the items8-items12.
Recomendados
Recomendados
Más contenido relacionado
Similar a Ejp 01
Similar a Ejp 01 (20)
Ejp 01
- 1. Effective Java Presentation – 01 Method Common to All Objects (ch – 03) By Md. Fasihul Kabir
- 2. Content Overview Obey the general contract when overriding equals (Item 8) Always override hashCode when you override equals (Item 9) Always override toString (Item 10) Override clone judiciously (Item 11) Consider implementing comparable (Item 12)
- 3. Obey the general contract when overriding equals
- 4. Best Approach – Avoid! Works if Each instance of a class is unique You don’t care if class has logical equality The superclass equals is satisfactory Class is not public and equals method never will be invoked
- 5. Best Approach – Avoid! Works if Each instance of a class is unique You don’t care if class has logical equality The superclass equals is satisfactory Class is not public and equals method never will be invoked
- 6. General Contract for equals Reflexive x.equals(x) must return true Symmetric x.equals(y) iff y.equals(x) Transitive x.equals(y) && y.equals(z) Then x.equals(z) Consistency Null values x.equals(null) must return false
- 7. Symmetry
- 8. Symmetry (Cont.) x equals to y :: true y equals to x :: false
- 9. Symmetry (Cont.) x equals to y :: true y equals to x :: false
- 10. Symmetry (Cont.)
- 11. How to Implement equals() Use == to see if argument is a reference to this object Use instanceof to check if argument is of the correct type Cast the argument to the correct type Check each “significant field” Check symmetric, transitive, consistent
- 12. What to Do Always override hashCode when override equals Don’t substitute another type for Object Don’t throw NullPointerException or ClassCastException
- 13. Always override hashCode when you override equals
- 14. Contract hashCode() must return same interger on different calls, as long as equals() unchanged If x.equals(y) is true, then x, y must have same hashcode It is not required that unequal objects have different hashcodes
- 18. Simple Recipe Start with some nonzero value Say, result = 17; (Repeatedly) compute in hashCode “c” for each “significant field” Apply various rules for each data type Combine result = result*37 + c;
- 19. Optimize hashCode() for immutable objects
- 21. “It is recommended that all subclasses override this method.” Good advice, indeed! Providing a good toString implementation makes your class much more pleasant to use Return all of the interesting information contained in the object Clearly document your intentions Provide getters for values toString() provides
- 23. Contract x.clone() != x x.clone().getClass() = x.getClass() x.clone().equals(x) will be true No constructors are called
- 24. The role of mutability If a class has only primitive fields or immutable references as fields, super.clone() returns exactly what you want For objects with mutable references, “deep copies” are required
- 25. Cloning Problems Cloning may be a problem with final fields Cloning recursively may not be sufficient
- 26. Other Mechanism Better off not implementing Cloneable Provide a separate copy mechanism Copy Constructor: public ClassA ( ClassA a ) Factory public static ClassA newInstance ( ClassA a )
- 28. Contract x.compareTo(y) = - y.compareTo(x) If x.compareTo(y)>0 && y.compareTo(z)>0, then x.compareTo(z) must be greater than 0 If x.compareTo(y)==0, then sign(x.compareTo(z))==sign(y.compareTo(z)) It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y))
- 30. Inconsistent with equals (Cont.) x.equals(y) :: false x.compareTo(y) :: 0
- 31. Inconsistent with equals (Cont.)
- 32. Inconsistent with equals (Cont.) Size of Set s :: 2 Size of Set h :: 1
- 33. Thanks
Notas del editor
- # This is true for classes such as Thread that represent active entities rather than values.# For example, java.util.Random could have overridden equals to check whether two Random instances would produce the same sequence of random numbers going forward, but the designers didn’t think that clients would need or want this functionality. # For example, most Set implementations inherit their equals implementation from AbstractSet, List implementations from AbstractList, and Map implementations from AbstractMap.@
- # This is true for classes such as Thread that represent active entities rather than values.# For example, java.util.Random could have overridden equals to check whether two Random instances would produce the same sequence of random numbers going forward, but the designers didn’t think that clients would need or want this functionality. # For example, most Set implementations inherit their equals implementation from AbstractSet, List implementations from AbstractList, and Map implementations from AbstractMap.
- # This is just a performance optimization
- Notice that two PhoneNumber instances are involved: one is used for insertion into the HashMap, and a second, equal, instance is used for (attempted) retrieval. The PhoneNumber class’s failure to override hashCode causes the two equal instances to have unequal hash codes, in violation of the hashCode contract. Therefore the get method is likely to look for the phone number in a different hash bucket from the one in which it was stored by the put method. Even if the two instances happen to hash to the same bucket, the get method will almost certainly return null, as HashMap has an optimization that caches the hash code associated with each entry and doesn’t bother checking for object equality if the hash codes don’t match.
- # It’s legal because it ensures that equal objects have the same hash code. It’s atrocious because it ensures that every object has the same hash code. Therefore, every object hashes to the same bucket, and hash tables degenerate to linked lists. Programs that should run in linear time instead run in quadratic time. For large hash tables, this is the difference between working and not working.