Ejp 01

318 views
259 views

Published on

Presentation on "Effective Java" Book's chapter-03. Basically I covered the items8-items12.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
318
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • # 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.
  • Ejp 01

    1. 1. Effective Java Presentation – 01Method Common to All Objects (ch – 03)By Md. Fasihul Kabir
    2. 2. Content Overview Obey the general contract when overriding equals(Item 8) Always override hashCode when you overrideequals (Item 9) Always override toString (Item 10) Override clone judiciously (Item 11) Consider implementing comparable (Item 12)
    3. 3. Obey the general contract whenoverriding equals
    4. 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 beinvoked
    5. 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 beinvoked
    6. 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. 7. Symmetry
    8. 8. Symmetry (Cont.)x equals to y ::truey equals to x ::false
    9. 9. Symmetry (Cont.)x equals to y ::truey equals to x ::false
    10. 10. Symmetry (Cont.)
    11. 11. How to Implement equals() Use == to see if argument is a reference to thisobject Use instanceof to check if argument is of the correcttype Cast the argument to the correct type Check each “significant field” Check symmetric, transitive, consistent
    12. 12. What to Do Always override hashCode when override equals Don’t substitute another type for Object Don’t throw NullPointerException orClassCastException
    13. 13. Always override hashCode whenyou override equals
    14. 14. Contract hashCode() must return same interger on differentcalls, as long as equals() unchanged If x.equals(y) is true, then x, y must have samehashcode It is not required that unequal objects have differenthashcodes
    15. 15. Avoiding hashCode
    16. 16. Avoiding hashCode (Contd.)
    17. 17. Simple hashCode Implementation
    18. 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. 19. Optimize hashCode() for immutableobjects
    20. 20. Always override toString
    21. 21.  “It is recommended that all subclasses override thismethod.” Good advice, indeed! Providing a good toString implementation makesyour class much more pleasant to use Return all of the interesting information contained inthe object Clearly document your intentions Provide getters for values toString() provides
    22. 22. Override clone judiciously
    23. 23. Contract x.clone() != x x.clone().getClass() = x.getClass() x.clone().equals(x) will be true No constructors are called
    24. 24. The role of mutability If a class has only primitive fields or immutablereferences as fields, super.clone() returns exactlywhat you want For objects with mutable references, “deep copies”are required
    25. 25. Cloning Problems Cloning may be a problem with final fields Cloning recursively may not be sufficient
    26. 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 )
    27. 27. Consider implementatingcomparable
    28. 28. Contract x.compareTo(y) = - y.compareTo(x) If x.compareTo(y)>0 && y.compareTo(z)>0, thenx.compareTo(z) must be greater than 0 If x.compareTo(y)==0, thensign(x.compareTo(z))==sign(y.compareTo(z)) It is strongly recommended, but not strictly requiredthat(x.compareTo(y)==0) == (x.equals(y))
    29. 29. Inconsistent with equals
    30. 30. Inconsistent with equals (Cont.)x.equals(y) :: falsex.compareTo(y) :: 0
    31. 31. Inconsistent with equals (Cont.)
    32. 32. Inconsistent with equals (Cont.)Size of Set s :: 2Size of Set h :: 1
    33. 33.  Thanks 

    ×