lombok踩坑與思考
雖然接觸到lombok已經有很長時間，但是大量使用lombok以減少代碼編寫還是在新團隊編寫新代碼維護老代碼中遇到的。
我個人並不主張使用lombok，其帶來的代價足以抵消其便利，但是由於團隊編碼風格需要一致，用還是要繼續使用下去。使用期間遇到了一些問題並進行了一番研究和思考，記錄一下。
1. 一些雜七雜八的問題
這些是最初我不喜歡lombok的原因。
1.1 額外的環境配置
作為IDE插件+jar包，需要對IDE進行一系列的配置。目前在idea中配置還算簡單，幾年前在eclipse下也配置過，會復雜不少。
1.2 傳染性
一般來說，對外打的jar包最好盡可能地減少三方包依賴，這樣可以加快編譯速度，也能減少版本沖突。一旦在resource包裏用了lombok，別人想看源碼也不得不裝插件。
而這種不在對外jar包中使用lombok僅僅是約定俗成，當某一天lombok第一次被引入這個jar包時，新的感染者無法避免。
1.3 降低代碼可讀性
定位方法調用時，對於自動生成的代碼，getter/setter還好說，找到成員變量後find usages，再根據上下文區分是哪種；equals()這種，想找就只能寫段測試代碼再去find usages了。
目前主流ide基本都支持自動生成getter/setter代碼，和lombok註解相比不過一次鍵入還是一次快捷鍵的區別，實際減輕的工作量十分微小。
2. @EqualsAndHashCode和equals()
2.1 原理
當這個註解設置callSuper=true
public boolean equals(Object o) { if (o == this) { return true; } else if (!(o instanceof BaseVO)) { return false; } else { BaseVO other = (BaseVO)o; if (!other.canEqual(this)) { return false; } else if (!super.equals(o)) { return false; } else { // 各項屬性比較 } } }
如果一個類的父類是Object（java中默認沒有繼承關系的類父類都是Object），那麽這裏會調用Object的equals()方法，如下
public boolean equals(Object obj) {
return (this == obj);
}2.2 問題
對於父類是Object且使用了@EqualsAndHashCode(callSuper = true) 註解的類，這個類由lombok生成的equals()方法只有在兩個對象是同一個對象時，才會返回true，否則總為false，無論它們的屬性是否相同。這個行為在大部分時間是不符合預期的，equals()失去了其意義。即使我們期望equals()是這樣工作的，那麽其余的屬性比較代碼便是累贅，會大幅度降低代碼的分支覆蓋率。以一個近6000行代碼的業務系統舉例，是否修復該問題並編寫對應測試用例，可以使整體的jacoco分支覆蓋率提高10%~15%。
相反地，由於這個註解在jacoco下只算一行代碼，未覆蓋行數倒不會太多。
2.3 解決
有幾種解決方法可以參考：
- 不使用該註解。大部分pojo我們是不會調用equals進行比較的，實際用到時再重寫即可。
- 去掉
callSuper = true。如果父類是Object，推薦使用。 - 重寫父類的equals()方法，確保父類不會調用或使用類似實現的Ojbect的equals()。
2.4 其他
@data註解包含@EqualsAndHashCode註解，由於不調用父類equals()，避免了Object.equals()的坑，但可能帶來另一個坑。詳見@data章節。
3. @data
3.1 從一個坑出來掉到另一個大坑
上文提到@EqualsAndHashCode(callSuper = true) 註解的坑，那麽 @data 是否可以避免呢？很不幸的是，這裏也有個坑。
由於 @data 實際上就是用的 @EqualsAndHashCode，沒有調用父類的equals()，當我們需要比較父類屬性時，是無法比較的。示例如下：
@Data
public class ABO {
private int a;
}
@Data
public class BBO extends ABO {
private int b;
public static void main(String[] args) {
BBO bbo1 = new BBO();
BBO bbo2 = new BBO();
bbo1.setA(1);
bbo2.setA(2);
bbo1.setB(1);
bbo2.setB(1);
System.out.print(bbo1.equals(bbo2)); // true
}
}很顯然，兩個子類忽略了父類屬性比較。這並不是因為父類的屬性對於子類是不可見——即使把父類private屬性改成protected，結果也是一樣——而是因為lombok自動生成的equals()只比較子類特有的屬性。
3.2 解決方法
- 用了
@data就不要有繼承關系，類似kotlin的做法，具體探討見下一節 - 自己重寫equals()，lombok不會對顯式重寫的方法進行生成
- 顯式使用
@EqualsAndHashCode(callSuper = true)。lombok會以顯式指定的為準。
3.3 關於@data和data
在了解了 @data 的行為後，會發現它和kotlin語言中的data修飾符有點像：都會自動生成一些方法，並且在繼承上也有問題——前者一旦有繼承關系就會踩坑，而後者修飾的類是final的，不允許繼承。kotlin為什麽要這樣做，二者有沒有什麽聯系呢？在一篇流傳較廣的文章(拋棄 Java 改用 Kotlin 的六個月後，我後悔了(譯文))中，對於data修飾符，提到：
Kotlin 對 equals()、hashCode()、toString() 以及 copy() 有很好的實現。在實現簡單的DTO 時它非常有用。但請記住，數據類帶有嚴重的局限性。你無法擴展數據類或者將其抽象化，所以你可能不會在核心模型中使用它們。
這個限制不是 Kotlin 的錯。在 equals() 沒有違反 Liskov 原則的情況下，沒有辦法產生正確的基於值的數據。
對於Liskov（裏氏替換）原則，可以簡單概括為：
一個對象在其出現的任何地方，都可以用子類實例做替換，並且不會導致程序的錯誤。換句話說，當子類可以在任意地方替換基類且軟件功能不受影響時，這種繼承關系的建模才是合理的。
根據上一章的討論，equals()的實現實際上是受業務場景影響的，無論是否使用父類的屬性做比較都是有可能的。但是kotlin無法決定equals()默認的行為，不使用父類屬性就會違反了這個原則，使用父類屬性有可能落入調用Object.equals()的陷阱，進入了兩難的境地。
kotlin的開發者回避了這個問題，不使用父類屬性並且禁止繼承即可。只是kotlin的使用者就會發現自己定義的data對象沒法繼承，不得不刪掉這個關鍵字手寫其對應的方法。
回過頭來再看 @data ，它並沒有避免這些坑，只是把更多的選擇權交給開發者決定，是另一種做法。
4. 後記
其他lombok註解實際使用較少，整體閱讀了 官方文檔暫時沒有發現其他問題，遇到以後繼續更新。
實際上官方文檔中也提到了equals()的坑。
lombok踩坑與思考