結果變成這樣嗎？
p with { x = 3; }
因為沒辦法加上 default parameters 所以又要創新語法/keyword 了。
上次那個 switch 也是又加了一堆新結構，Java 的語法新方向感覺 style 沒有很統一。不像 kotlin 的概念都一樣，又融合的很好…
Never 在 kotlin 是 Nothing
Dart 也偷了一些 c# 的概念
String? 是 String | Null 的 union type，不像 kotlin 是用 hack 的。可以預見未來Dart 和 typescript 一樣會有更多的 union type 支援
Dart 2.0 還可以重開機，加上 null safety ，但 Java 大概永遠沒辦法了，盡管 Java 最近很死命的想追上其他現代化語言…
dev, production 都可用
怕的話就 local 玩一玩就好，算是最簡單的方式建立一個 k8s 環境，然後資源用的很少。
去裝 minikube 或是 Docker Desktop 內建的 k8s 就知道，裡面什麼都沒裝就吃掉 30% CPU usage，這真的抓狂
kaif 哪天我也會轉到 k3s 吧… 有空的話 XD
基本上新設計的 date API 多半都有 Java8 time API 的影子 -- 分為機器產生的絕對時間和人使用的曆法時間
Absolute -- Java 8 Instant
DateTime -- Java 8 LocalDateTime
不過沒看到相對應的 ZonedDateTime 或是 OffsetDateTime，只有轉 string 時才會出現。
這個嘛... 我猜未來 proposal 會加上去吧，而且 Absolute 這個字大概會被改掉，因為明明文件裡就一直出現 instant 這個字。
所以要寫 test
如果比較好測，那通常是比較好的設計。你通常也只會重構到測試不會太難寫這樣，不會太過頭。(class 太多就測試更多，想到這你就會懶得抽這麼多層了)
測試可以引導設計，再加上一些經驗的累積大概不會錯太多。
當然如果寫的是 library ，會放出來給別人用，那又是另一種規則。
這篇又浮上來了
method 加上參數，裡面多寫個 if 進行擴充 -- 這大概工程師每天都在做
所以我覺得這類型的還好，它要累積到一個程度之後，才要重構，看是要回到重覆或是抽得更多層。
出現問題的大部份都是太多參數，就是作者說的，抽象化錯了方向。另一種錯誤是太早將單純的 if 抽成更複雜的 class/interface，也不能說一定錯，但新需求多半不可預知，所以八成都是抽錯方向，不如不抽。
然後更難得問題是，這些修改不一定是同一個人做的…