lombok優缺點

優勢：

1. 能經過註解的形式自動生成構造器、getter/setter、equals、hashcode、toString等方法，提升了必定的開發效率
2. 讓代碼變得簡潔，不用過多的去關注相應的方法
3. 屬性作修改時，也簡化了維護爲這些屬性所生成的getter/setter方法等

缺點：

1. 不支持多種參數構造器的重載
2. 雖然省去了手動建立getter/setter方法的麻煩，但大大下降了源代碼的可讀性和完整性，下降了閱讀源代碼的溫馨度

 

 

Lombok總結： 

Lombok雖然有不少優勢，但Lombok更相似於一種IDE插件，項目也須要依賴相應的jar包。Lombok依賴jar包是由於編譯時要用它的註解，爲何說它又相似插件？由於在使用時，eclipse或IntelliJ IDEA都須要安裝相應的插件，在編譯器編譯時經過操做AST（抽象語法樹）改變字節碼生成，變向的就是說它在改變java語法。它不像spring的依賴注入或者mybatis的ORM同樣是運行時的特性，而是編譯時的特性。這裏我我的最感受不爽的地方就是對插件的依賴！由於Lombok只是省去了一些人工生成代碼的麻煩，但IDE都有快捷鍵來協助生成getter/setter等方法，也很是方便。

知乎上有位大神發表過對Lombok的一些見解：

這是一種低級趣味的插件，不建議使用。JAVA發展到今天，各類插件層出不窮，如何甄別各類插件的優劣？能從架構上優化你的設計的，能提升應用程序性能的 ，
實現高度封裝可擴展的...， 像lombok這種，像這種插件，已經不單單是插件了，改變了你如何編寫源碼，事實上，少去了代碼你寫上去又如何？ 
若是JAVA家族處處充斥這樣的東西，那隻不過是一坨披着金屬顏色的屎，早晚會被其它的語言取代。

雖然話糙但理確實不糙，試想一個項目有很是多相似Lombok這樣的插件，我的以爲真的會極大的下降閱讀源代碼的溫馨度。

雖然很是不建議在屬性的getter/setter寫一些業務代碼，但在多年項目的實戰中，有時經過給getter/setter加一點點業務代碼，能極大的簡化某些業務場景的代碼。所謂取捨，也許就是這時的捨棄必定的規範，取得極大的方便。

我如今很是堅信一條理念，任何編程語言或插件，都僅僅只是工具而已，即便工具再強大也在於用的人，就如同小米加步槍照樣能贏飛機大炮的道理同樣。結合具體業務場景和項目實際狀況，無需一味追求高大上的技術，適合的纔是王道。

Lombok有它的得天獨厚的優勢，也有它避之不及的缺點，熟知其優缺點，在實戰中靈活運用纔是王道。

 

 

 

原文：https://www.cnblogs.com/heyonggang/p/8638374.html

 

聲明：此博客爲我的學習之用，如與其餘做品雷同，純屬巧合，轉載請指明出處！