Effective Java Item10 - 覆蓋equals請遵守通用規範

June 16, 2018

這篇是Effective Java - Obey the general contract when overriding equals章節的讀書筆記本篇的程式碼來自於原書內容

Item10: 覆蓋equals請遵守通用規定

覆蓋equals方法看似簡單但有許多覆蓋方式會導致錯誤最簡單的避免方式就是不要覆蓋equals 那就代表說每個實例只會和自己一樣不會和別人一樣(即使所有內部變量的值都一樣)

什麼時候不應該覆蓋equals

只要滿足以下任一條件

1.類別的每個實例本質上都是唯一的

比如說Thread 代表的就是一個實體而不是一個值

2.類別不需要提供 邏輯相等 的測試

比如說java.util.regex.Pattern這個類別這個類別也許可以覆蓋equals 讓客戶比較兩個regex expression是不是相等但是並沒有客戶會這麼做所以Pattern類別就沒有覆蓋equals

3.超類已經覆蓋了equals 以超類繼承過來的行為對於子類也是合適的

比如說 Set從AbstractSet繼承了equals, List從AbstractList繼承了equals, Map從AbstractMap繼承了equals

以上任一條件滿足你就不應該要覆蓋equals

當然你也可以極端一點你的類別不想讓任何人呼叫equals 你也可以直接拋出例外

@Override public boolean equals(Object o) {
  throw new AssertionError(); // Method is never called
}

什麼時候應該覆蓋equals

通常是值類(value class) 比如說Integer或是Date

當程序員在呼叫equals的時候他們希望知道他們在邏輯上是否相等而不是想知道他們是不是指到同一個對象 當你的客戶有這種需求時你就必須覆蓋equals

如果你不這麼做你甚至無法把你的類別放進Map的key或是Set的key

不過有一種值類不需要覆蓋equals 就是有實例控制的類別(比如說最多只能存在一個實例) 比如說Enum 對於這種類來說邏輯相同跟對象等同是同一件事

覆蓋的約束

當你決定要覆蓋equals的時候你必須要遵守通用約定如下

equals方法必須實現等價關係(equivalence relation)

等價關係代表

1.自反性(reflexive): 對於非null的值x x.equals(x) 回傳true

2.對稱性(symmetric): 對於非null的值x和y 如果x.equals(y) 回傳true 那 y.equals(x) 回傳true

3.傳遞性(transitive): 對於非null的值x和y和z 如果x.equals(y) 回傳true 且 y.equals(z) 回傳true 則x.equals(z) 回傳true

4.一致性(consistent): 對於非null的值x和y 多次呼叫x.equals(y)應該一直回傳同樣的值

5.非空性(Non-nullity): 對於非null的值x x.equals(null) 返回false

只要違反了任一一個你的程序就會表現不正常

違反的下場和例子

自反性

只要有任何一個x違反這個要求則你把x放進任意的collection 第二次的時候他的contains(x)會回傳false 你就可以再放進去一次因為collection以為這東西沒出現過

對稱性

來看個可愛的例子我們有一個不管大小寫的字串

public final class CaseInsensitiveString {
  private final String s;
  public CaseInsensitiveString(String s) {
    if (s == null)
      throw new NullPointerException();
    this.s = s;
  }
}

它覆蓋了equals

@Override 
public boolean equals(Object o) {
  if (o instanceof CaseInsensitiveString)
    return s.equalsIgnoreCase(((CaseInsensitiveString) o).s);
  if (o instanceof String) // One-way interoperability!
    return s.equalsIgnoreCase((String) o);
  return false;
}

看起來挺正常的現在來一個正常的字串跟一個不管大小寫的字串

CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
String s = "polish";
cis.equals(s) // return ture
s.equals(cis) // return false

因為我們知道CaseInsensitiveString的equals裡面有特別處理String的case

但String哪看得懂什麼是CaseInsensitiveString?

所以正確的複寫方法應該是

@Override public boolean equals(Object o) {
  return o instanceof CaseInsensitiveString &&
    ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
}

傳遞性

有趣的來了先來一個Point類別

public class Point {
  private final int x;
  private final int y;

  public Point(int x, int y) {
    this.x = x;
    this.y = y;
  }

  @Override
  public boolean equals(Object o) {
    if (!(o instanceof Point))
      return false;
    Point p = (Point) o;
    return p.x == x && p.y == y;
  }
}

現在我想繼承Point之後加一個變量代表這個點的顏色

public class ColorPoint extends Point {
  private final Color color;

  public ColorPoint(int x, int y, Color color) {
    super(x, y);
    this.color = color;
  }
}

端上最直觀的equals

@Override
public boolean equals(Object o) {
  if (!(o instanceof ColorPoint))
    return false;
  return super.equals(o) && ((ColorPoint) o).color == color;
}

剛剛說過了這個解法會違反對稱性

可不可以我們在equals裡面判斷如果傳進來的是ColorPoint 我們就比較x, y 跟color

除果傳進來的是Point 我們就只比較x, y

@Override public boolean equals(Object o) {
  if (!(o instanceof Point))
    return false;

  // If o is a normal Point, do a color-blind comparison
  if (!(o instanceof ColorPoint))
    return o.equals(this);

  // o is a ColorPoint; do a full comparison
  return super.equals(o) && ((ColorPoint)o).color == color;
}

這個解法的確是解決了對稱性的問題但是傳遞性卻沒有遵守

Point p = new Point(1, 2);
ColorPoint cp = new ColorPoint(1, 2, Color.RED);
p.equals(cp)//true
cp.equals(p)//true 遵守對稱性

ColorPoint p1 = new ColorPoint(1, 2, Color.RED);
Point p2 = new Point(1, 2);
ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE);
p1.equals(p2)//true
p2.equals(p3)//true
p1.equals(p3)//false 違反傳遞性

因為p1和p2只比較座標 p2和p3也只比較座標

好啦我知道了啦我用你剛剛在對稱性教的方法寫equals就是了嘛

@Override public boolean equals(Object o) {
  return (o instanceof ColorPoint) 
    && super.equals(o) 
    && ((ColorPoint)o).color == color;
}

不好意思這樣寫還是違反對稱性

因為這種情況下 p.equals(cp) return true

這是什麼道理為什麼同樣寫法(父類.equals(子類)) 前一個例子卻s.equals(cis) return false呢?

在effective java的這個章節中前後的段落很不連貫一下子把所有的觀念一次丟出來可是前因後果卻沒有解釋清楚看了這篇文章你才會知道為什麼

希望讀者看到這裡可以想一下如果你能自己想到為什麼的話請按左下角的linkedin按鈕與我聯繫我很願意幫你refer linkedin

給你十分鐘

再現高壇

答案就是繼承做不到

因為我們ColorPoint繼承了Point

我們無法在擴展可實例化的類的同時既增加新的值組件同時又保留equals約定

那該怎麼辦呢記不記得有一個東西一直比繼承好用有彈性

那個東西就是復合

public class ColorPointComposition {
  private final Point point;
  private final Color color;

  public ColorPointComposition(int x, int y, Color color) {
    if (color == null) {
      throw new NullPointerException();
    }
    this.point = new Point(x, y);
    this.color = color;
  }
}

Point變成了一個新類別的一個變量這樣事情就非常好辦

@Override public boolean equals(Object o) {
  if (!(o instanceof ColorPointComposition)) {
    return false;
  }
  ColorPointComposition cp = (ColorPointComposition) o;
  return cp.point.equals(point) && cp.color.equals(color);
}

這就是復合厲害的地方

一致性

如果兩個對象相等那這兩個對象就要一直相等(除了有人被改了) 意思就是一個可變對象在不同時候可以跟不同對象相等所以如果你的對象是不可變對象那兩個不相等的對象就應該永遠不相等

非空性

所有對象都必須不等於null

基本上很少情況會讓你的x.equals(null) 回傳true 但是如果你沒寫好是有可能拋出NullPointerException的照慣例 equals方法不允許拋出NullPointerException

也許不少人會這麼寫

@Override 
public boolean equals(Object o) {
  if (o == null)
    return false;
}

但這是沒有必要的因為equals的輸入參數是Object 所以你幾乎會被迫檢查物件的型態

@Override public boolean equals(Object o) {
  if (!(o instanceof MyType))
    return false;
  MyType mt = (MyType) o;
  ...
}

而instanceof會在第一個型態給null的時候直接return false

所以單獨的null檢查是沒有必要的

所以要怎麼寫equals

1.在一個equals的一開始直接用==判斷參數是否是這個對象的引用如果是就直接傳true 少了後面很多昂貴的計算

2.用instanceof檢查參數類型是否正確

3.把參數轉成正確類型

4.一一檢查類別中的每個關鍵域(Significant field)

如果所有關鍵域的測試都成功就回傳true 其中:

4-1.對於非float跟非double的基本類型可以使用==

4-2.對於引用對象可以使用equals(剩下的交給遞迴處理)

4-3.對於float 可以用Float.compare

4-4.對於double 可以用Double.compare

4-5.對於數組則每個元素都要套用以上的原則

對於有些對象引用域來說 null值是合法的為了避免NPE 你可以用Objects.equals(Object, Object) 來比

5.域的比較順序也會影響到效能把最有可能不一致的或是開銷最低的拿來先比較

道理就跟 A且B且C 的時候最有可能錯的擺最前面但是A或B或C 的時候最有可能對的擺最前面一樣道理

6.當你寫完equals方法問自己三個問題他是否是對稱的傳遞的一致的自反性以及非空性並且為這些特性都寫unit test

其他注意事項

1.覆蓋equals時總要覆蓋hashCode

2.不要企圖讓equals方法太過複雜

只要遵循這篇文章講的規範就可以如果你除了這些規範之外還想去測試其他的等價關係可能不會是個好主意比如說有個類別裡面有網址如果你去比較不同實例的網址是不是指到同一個網站(比如說其中一個是縮網址) 會太過複雜

3.不要把equals的輸入參數改成其他類型

public boolean equals(MyClass o) {
...
}

你很可能這樣寫完之後會花好幾個小時debug

為什麼呢因為這個並沒有複寫(override)到equals(Object o) 而是重載(overload)了Object.equals(詳見Item52 - 慎用重載)

4.用Override annotation

這樣第三點就不會犯因為方法簽名不一樣

總結

如果不需要就不要覆寫equals 大多數情況從Object繼承而來的equals就做得到你想做的事

當你真的要覆寫保證你有比較每個significant fields 並且保證每個約束都有被遵守

jyt0532's Blog

Effective Java Item10 - 覆蓋equals請遵守通用規範

Item10: 覆蓋equals請遵守通用規定

什麼時候不應該覆蓋equals

什麼時候應該覆蓋equals

覆蓋的約束

違反的下場和例子

自反性

對稱性

傳遞性

再現高壇

一致性

非空性

所以要怎麼寫equals

其他注意事項

總結

相關文章

jyt0532's Blog

Effective Java Item10 - 覆蓋equals請遵守通用規範

Item10: 覆蓋equals請遵守通用規定

什麼時候不應該覆蓋equals

什麼時候應該覆蓋equals

覆蓋的約束

違反的下場和例子

自反性

對稱性

傳遞性

再現高壇

一致性

非空性

所以要怎麼寫equals

其他注意事項

總結

相關文章

Effective Java Item5 - 依賴注入優於硬連接資源 17 Mar 2020

Effective Java Item31 - 利用限制通配符來提昇API靈活性 23 Dec 2018

到底 <T extends Comparable<? super T>>是什麼意思 23 Dec 2018

類型參數和通配符的選擇 23 Dec 2018