12/21 学习笔记 hashcode String

1.看了有关immutable class的资料， 

An object is considered immutable if its state cannot change after it is constructed. Maximum reliance on immutable objects is widely accepted as a sound strategy for creating simple, reliable code.

Immutable objects are particularly useful in concurrent applications. Since they cannot change state, they cannot be corrupted by thread interference or observed in an inconsistent state.

例如， 如果创建了一个object，它的field全部都是privte的， 然后又都是String，又没有方法去set 他们， 那么这个class就是immutable的， All other things being equal, immutable types are the way to go, especially for objects that will be used as elements in Sets or as keys in Maps. These collections will break if you modify their elements or keys while they're in the collection.

https://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html

https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html

2 看了有关comparable interface 还有comparator 的资料

3 hashcode()

https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html

his is essential for any class that redefines the equals method. (Equal objects must have equal hash codes.)

public int hashCode()

Returns a hash code value for the object. This method is supported for the benefit of hash tables such as those provided by  HashMap.

The general contract of hashCode is:

• 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.
• 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.
• 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 hash tables.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java^TM programming language.)

Returns:

a hash code value for this object.

4 很好的关于comparator, comparable interface 的文章

https://docs.oracle.com/javase/tutorial/collections/interfaces/order.html

关键点小结：

1 omparable implementations provide a natural ordering for a class, which allows objects of that class to be sorted automatically. The following table summarizes some of the more important Java platform classes that implement Comparable.

2 

What if you want to sort some objects in an order other than their natural ordering? Or what if you want to sort some objects that don't implement Comparable? To do either of these things, you'll need to provide a Comparator — an object that encapsulates an ordering. Like the Comparable interface, the Comparator interface consists of a single method.

public interface Comparator<T> {
    int compare(T o1, T o2);
}

3 注意点：

  
  

   
   
// Don't do this!!
return -r1.hireDate().compareTo(r2.hireDate());

  
  
You should always use the former technique in favor of the latter because the latter is not guaranteed to work. The reason for this is that the compareTo method can return any negative int if its argument is less than the object on which it is invoked. There is one negative int that remains negative when negated, strange as it may seem.
  
  

   
   
-Integer.MIN_VALUE == Integer.MIN_VALUE
  
  

  
  

   
   

   
   
4
   
   
return (e1.number() < e2.number() ? -1 :
               (e1.number() == e2.number() ? 0 : 1));
    }
};

  
  
One last note: You might be tempted to replace the final return statement in the Comparator with the simpler:
  
  

   
   
return e1.number() - e2.number();

  
  
Don't do it unless you're absolutely sure no one will ever have a negative employee number! This trick does not work in general because the signed integer type is not big enough to represent the difference of two arbitrary signed integers. If i is a large positive integer and j is a large negative integer, i - j will overflow and will return a negative integer. The resulting comparator violates one of the four technical restrictions we keep talking about (transitivity) and produces horrible, subtle bugs. This is not a purely theoretical concern; people get burned by it.

5 今天做题的时候犯的一些错误：
StirngBuffer deleteCharAt() 这个方法是在这个buffer上做的改变， 不是return一个新的StringBuffer, 所以要想在原来的基础上分别删除一个char， 就要新建很多个buffer