Your SlideShare is downloading. ×
Ejp 01
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ejp 01

100
views

Published on

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

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
100
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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.
  • Transcript

    • 1. Effective Java Presentation – 01Method 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 overrideequals (Item 9) Always override toString (Item 10) Override clone judiciously (Item 11) Consider implementing comparable (Item 12)
    • 3. Obey the general contract whenoverriding 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 beinvoked
    • 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. 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 ::truey equals to x ::false
    • 9. Symmetry (Cont.)x equals to y ::truey equals to x ::false
    • 10. Symmetry (Cont.)
    • 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. What to Do Always override hashCode when override equals Don’t substitute another type for Object Don’t throw NullPointerException orClassCastException
    • 13. Always override hashCode whenyou override equals
    • 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. Avoiding hashCode
    • 16. Avoiding hashCode (Contd.)
    • 17. Simple hashCode Implementation
    • 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 immutableobjects
    • 20. Always override toString
    • 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. Override clone judiciously
    • 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 immutablereferences as fields, super.clone() returns exactlywhat 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 )
    • 27. Consider implementatingcomparable
    • 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. Inconsistent with equals
    • 30. Inconsistent with equals (Cont.)x.equals(y) :: falsex.compareTo(y) :: 0
    • 31. Inconsistent with equals (Cont.)
    • 32. Inconsistent with equals (Cont.)Size of Set s :: 2Size of Set h :: 1
    • 33.  Thanks 

    ×