分析Kotlin和Java EE的關系
本文分析了Kotlin和Java EE的關系，討論了如何利用Kotlin的運算符，可空性和可選項來優(yōu)化轉換的效果。
將Java EE應用程序轉換為Kotlin開始于框架的戰(zhàn)斗，我們成功地超越了java老標準設置的所有障礙。在此過程中，新時代語言Kotlin特定的構造，使的代碼更簡潔而安全。
如果您沒有閱讀本系列的前兩部分，可以在這里找到：
Kotlin和Java EE：第一部分 - 從Java到Kotlin（https://dzone.com/articles/kotlin-jee-part-one-from-java-to-kotlin）
Kotlin和Java EE：第二部分 - 插件的樂趣（https://dzone.com/articles/kotlin-and-java-ee-part-2-having-fun-with-plugins）
經過對前面兩部分的回顧及修改，這里補充最后一些內容。
已有的轉換
前兩部分中的許多結構已經適用與Kotlin了。 下面我們來看看Set的定義：
由于Java不支持對象列表中的Set和其他集合的簡單構造，我們必須使用Arrays類來創(chuàng)建List，然后將其轉換為Set。Kotlin里就變成：
我們還將Java Bean轉換為Kotlin數(shù)據(jù)類，使得它們簡潔了很多。去掉所有的getter和setter，并自動得到了equals（），hashCode（）和toString（）。
這里要感謝編譯器插件，可以偽造不變的對象，而不需要無參數(shù)的構造函數(shù)：
用lateinit關鍵字處理那些由框架初始化的值更容易一些，可以避免不必要的空值檢查：
讓我們看看還有什么可以改進的。
空值還是可選項？
這是一個非常棘手的問題。 Kotlin對可空值有很好的支持，當您使用第三方庫時，這很有幫助。問題是當您有機會選擇一個時，該使用什么？這是我們原來的Optional生產者和消費者對：
Kotlin解決方案將使用空值，所以變成：
空值可以出現(xiàn)在調用鏈的每個步驟中，因此您必須對所有調用使用問號。這解決了可空性問題，但它不漂亮。
然而，如果返回類型為Optional，結果為Optional.empty，則將略過該對象的所有未來單調調用，結果將為Optional.empty。對我來說，這看起來是一個更干凈的解決方案，如果您打算從Java調用Kotlin代碼，它也是一個更安全的解決方案。對于Java互操作，優(yōu)先于空值。
運算符！
find， add ， 和 delete是完全合法的方法名稱，但是不是使用運算符更好呢？
MethodOperator
service.find（id）service［id］
service.add（kittenEntity）service += kittenEntity
我發(fā)現(xiàn)它不只是更短，而且更可讀，因為代碼不再是一大堆方法調用。小心只使用知名和易理解的操作符，否則，您將會遇到像Scala庫一樣大的混亂，然后您將需要一個操作符周期表。在數(shù)據(jù)存儲庫的情況下，類似MutableMap的接口工作得很好。請注意，我使用“plus assign”（+ =）運算符來持久化一個實體，因為原始集合包含它已經擁有的內容以及一個附加項。
以下是如何聲明它們：
您可能希望保留原始方法，并對操作符進行包裝，因為原始方法可以有返回值，而某些操作符則不能返回值。其他類似的選項是是“remove”和“contains”方法，因為它們可以用“minus assign”（ - =）和Kotlin的in運算符表示。其余的就留給你去探索。
結論
以慣用的方式寫Kotlin代碼的目的是要有更好的可讀性和更安全的代碼，我希望所提出的例子成功地實現(xiàn)了這一意圖。該系列僅顯示了幾種方法來改進Java代碼，同時使某些部分保持不變。值得探索的特點是：擴展函數(shù)，如果可能的話何時擴展，try/catch作為函數(shù)。探索一下，找出什么適合你的，玩得開心！
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%