這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。萬眾期待的 Golang 之於 DevOps 開發的利與弊 系列終於迴歸了！在這篇文章，我們討論下 Golang 中的 time 包，以及 go 語言中為什麼不使用方法重載。如果你沒有讀 [最近一篇](https://studygolang.com/articles/12614) 關於 “介面實現和公有/私人命名方式”（原文描述寫錯了，這一連結對應的應該是 “速度 vs. 缺少泛型”），請一定仔細閱讀下，你也可以 [訂閱我們的部落格更新](http://eepurl.com/cOHJ3f)，以後有系列文章發布的時候你就能收到通知。- [Golang 之於 DevOps 開發的利與弊（六部曲之一）：Goroutines, Channels, Panics, 和 Errors](https://studygolang.com/articles/11983)- [Golang 之於 DevOps 開發的利與弊（六部曲之二）：介面實現的自動化和公有/私人實現](https://studygolang.com/articles/12608)- [Golang 之於 DevOps 開發的利與弊（六部曲之三）：速度 vs. 缺少泛型](https://studygolang.com/articles/12614)- [Golang 之於 DevOps 開發的利與弊（六部曲之四）：time 包和方法重載](https://studygolang.com/articles/12615)- [Golang 之於 DevOps 開發的利與弊（六部曲之五）：跨平台編譯，Windows，Signals，Docs 以及編譯器](https://studygolang.com/articles/12616)- Golang 之於 DevOps 開發的利與弊（六部曲之六）：Defer 指令和包依賴性的版本控制## Golang 之利: Time 包的使用編程的人都知道處理 date 和 time 時候的危險。時間（time）在我們每天的生活中看似平常，可從電腦的角度看，time 處理簡直是噩夢。Google 有了這個機會使處理 date 變得輕鬆點，*他們成功了*！我將 [time 包](https://golang.org/pkg/time/) 的講解分成了三部分：（1）基本內容，（2）timer 定時器，（3）date 解析。### 1. Time 包基本內容你可能認為每一種語言都有一個標準的，易用的處理 time 操作的內建庫，其實不是這樣的。NPM 有超過 [8000 多個 time 相關的包](https://www.npmjs.com/search?q=time&page=1&ranking=quality)，因為 javascript 的 Date 包沒法用。Java8 最終使用 java.time.Instant 和 java.time.chrono 包緩解了這個問題，但仍在編寫 [教程](https://www.tutorialspoint.com/java8/java8_datetime_api.htm)，研究各種用 Java 操作 time 的類和方法。相反，Golang 的 [time 包](https://golang.org/pkg/time/) 用一句話就能總結：只需引用一個包，你想要的都能實現。擷取目前時間： `time.Now()`擷取將來某個時刻： `time.Now().Add(5*time.Minute)`擷取經過多少時間（期間）：` time.Since(processingStarted)`輕鬆地比較期間： `if frequency < time.Hour {`擷取當月日期，放棄 [calendar](http://https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html) 吧！ `time.Now().Day()` 就夠了### 2. Timers 定時器這個 time 包另一個大的加分項是使用 timer 定時器很方便。DevOps 的應用很明確：我們經常需要安排一些任務在將來執行，一些重複的基本操作，或者就是 sleep 一會。用 time 包裡的 co-locating 定時器，你可以輕鬆實現 sleep 一個線程，如```gotime.Sleep(2*time.Minute)```或者在將來的某個時刻執行一個函數```gotime.AfterFunc(5*time.Second, func() {fmt.Println("hello in the future")})```或者重複執行一個任務```gotick := time.NewTicker(1*time.Minute)select {case <- tick.C:foo()}```（這些操作）都不需要將時間轉換成 second（還是 millsecond 來著？），（也不用）添加 2 個依賴庫，（也不用）引入 10 個包。### 3. Date 解析不說下我們最常見又最討厭的話題：將字串轉成 date ，那關於 time 的討論就是不完整的。這本該是個初級問題，卻一點也不簡單。date 格式有 [諸多標準](https://en.wikipedia.org/wiki/ISO_8601)，[程式設計語言內部並沒有一個安全執行緒的實現](https://stackoverflow.com/questions/6840803/why-is-javas-simpledateformat-not-thread-safe) 來解析 date 和 [timezone](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)，就是為了確保不是所有的地方（同一時刻）都是 5 點鐘。這就是 Golang 意識到的重要的地方：其他人做的都是錯的。Google 沒有產生解決方案去處理成千上萬的 date 格式，而是建立了一套系統，使用基於 pattern 的設計，永遠參考同一個參照時間： Mon Jan 02 15:04:05 MST 2006 。組成這個單一參照時間的元素，可以重新組合成任何一種你可能遇到的格式。你可以在這裡（原文沒有連結，疑似 [這裡](https://golang.org/pkg/time/#example_Time_Format)）找到準確，完整的說明。當然，Golang 的 date 解析也不那麼完美，是吧？嗯，當然。你至少要考慮一個問題：timezone ，否則不能重新解析 date。除此之外，排程會議也大不可能了，還是因為 Golang 裡的 timezone，讓類似 “2017/10/03 4:07:22 America/New_York” 這樣的解析比較困難。“America/New_York” 這幾個 bit （解析起來）比較麻煩。有一些 [變通的解決辦法](https://stackoverflow.com/a/25368749)，不過 Golang 在解析 timezone 這部分還需要改進。## Golang 之弊: 函數重載我想起上電腦科學課時候的事，第一感覺就是“太酷了！”，但是在 Golang 裡完全不存在這種“酷”。以下來自 Golang FAQ：> 為什麼 Go 不支援方法和操作符重載？> 如果不用做類型匹配，方法調度過程也會簡化。使用其他語言的經驗告訴我們，一些有著同名但不同簽名的函數有時候很有用，不過實際使用中也會造成誤解，不夠健壯。> Go 類型系統主要使用的簡化決策是只通過函數名匹配，並且要求類型的一致性。就操作符的重載來說，似乎比絕對要求（類型一致性）方便。 不過還是，沒有重載會更簡單。當然，沒有方法重載確實更簡單。但這樣也會強制你想出唯一的函數名以防出現同名函數，這樣一來就增大了你的代碼量。如果你只是想複製粘貼下代碼，“以後再解”，還要記住共用函數是在私人的還是公用函數起作用。後面提到的 time 包有幾個這樣的執行個體，我們特別想用一個預設值替代最後那個選擇性參數。```gofunc Parse(layout, value string) (Time, error) { return parse(layout, value, UTC, Local)}func ParseInLocation(layout, value string, loc *Location) (Time, error) {return parse(layout, value, loc, loc)}func parse(layout, value string, defaultLocation, local *Location) (Time, error) {...}```[[原始碼地址]](https://golang.org/src/time/format.go?s=23626:23672#L762)這就是說，沒有方法重載絕不妨礙使用 Golang。在幾個我想用（重載）的執行個體中，我最終只用了一個共用的私人函數，和其它幾個不同名字的函數，或是刪除了我一開始說需要重載的原因。每隔一周左右，我們會發布一篇新指南，和本篇一樣都在 “Golang 之於 DevOps 開發的利與弊” 六部曲中。下一篇：#5：跨平台編譯， Windows ， Signals ，Docs 和編譯器。現在起 [訂閱我們的部落格吧](http://eepurl.com/cOHJ3f)，這樣你就不會錯過我們的文章發布了，如果你覺得你的開發人員朋友們能受益於瞭解 Golang 的利與弊，請把這篇博文分享給他們，尤其是有關 DevOps 生命週期的。感謝您閱讀和分享。
via: https://blog.bluematador.com/golang-pros-cons-part-4-time-package-method-overloading
作者：Matthew Barlocker 譯者：ArisAries 校對：polaris1119
本文由 GCTT 原創編譯，Go語言中文網 榮譽推出
本文由 GCTT 原創翻譯，Go語言中文網 首發。也想加入譯者行列，為開源做一些自己的貢獻嗎？歡迎加入 GCTT！
翻譯工作和譯文發表僅用於學習和交流目的，翻譯工作遵照 CC-BY-NC-SA 協議規定，如果我們的工作有侵犯到您的權益，請及時聯絡我們。
歡迎遵照 CC-BY-NC-SA 協議規定 轉載，敬請在本文中標註並保留原文/譯文連結和作者/譯者等資訊。
文章僅代表作者的知識和看法，如有不同觀點，請樓下排隊吐槽
305 次點擊
