万众期待的Golang之于DevOps开发的利与弊系列终于回归了！在这篇文章，我们讨论下Golang中的time包，以及go语言中为什么不使用方法重载。
如果你没有读最近一篇关于“接口实现和公有/私有命名方式”（原文描述写错了，这一链接对应的应该是“速度vs.缺少泛型”），请一定仔细阅读下，你也可以订阅我们的博客更新，以后有系列文章发布的时候你就能收到通知。
Golang之于DevOps开发的利与弊（六部曲之一）：Goroutines,Channels,Panics,和ErrorsGolang之于DevOps开发的利与弊（六部曲之二）：接口实现的自动化和公有/私有实现Golang之于DevOps开发的利与弊（六部曲之三）：速度vs.缺少泛型Golang之于DevOps开发的利与弊（六部曲之四）：time包和方法重载Golang之于DevOps开发的利与弊（六部曲之五）：跨平台编译，Windows，Signals，Docs以及编译器Golang之于DevOps开发的利与弊（六部曲之六）：Defer指令和包依赖性的版本控制Golang之利:Time包的使用
编程的人都知道处理date和time时候的危险。时间（time）在我们每天的生活中看似平常，可从计算机的角度看，time处理简直是噩梦。Google有了这个机会使处理date变得轻松点，他们成功了！我将time包的讲解分成了三部分：（1）基本内容，（2）timer定时器，（3）date解析。
1.Time包基本内容
你可能认为每一种语言都有一个标准的，易用的处理time操作的内置库，其实不是这样的。NPM有超过多个time相关的包，因为javascript的Date包没法用。Java8最终使用java.time.Instant和java.time.chrono包缓解了这个问题，但仍在编写教程，研究各种用Java操作time的类和方法。相反，Golang的time包用一句话就能总结：只需引用一个包，你想要的都能实现。
获取当前时间：time.Now()
获取将来某个时刻：time.Now().Add(5*time.Minute)
获取经过多少时间（持续时间）：time.Since(processingStarted)
轻松地比较持续时间：iffrequencytime.Hour{
获取当月日期，放弃calendar吧！time.Now().Day()就够了
2.Timers定时器
这个time包另一个大的加分项是使用timer定时器很方便。DevOps的应用很明确：我们经常需要安排一些任务在将来执行，一些重复的基本操作，或者就是sleep一会。
用time包里的co-locating定时器，你可以轻松实现sleep一个线程，如
1time.Sleep(2*time.Minute)或者在将来的某个时刻执行一个函数
1time.AfterFunc(5*time.Second,func(){2fmt.Println(hellointhefuture)3})或者重复执行一个任务
1tick:=time.NewTicker(1*time.Minute)2select{3case-tick.C:4foo()5}（这些操作）都不需要将时间转换成second（还是millsecond来着？），（也不用）添加2个依赖库，（也不用）引入10个包。
3.Date解析
不说下我们最常见又最讨厌的话题：将字符串转成date，那关于time的讨论就是不完整的。这本该是个初级问题，却一点也不简单。date格式有诸多标准，编程语言内部并没有一个线程安全的实现来解析date和timezone，就是为了确保不是所有的地方（同一时刻）都是5点钟。这就是Golang意识到的重要的地方：其他人做的都是错的。
Google没有生成解决方案去处理成千上万的date格式，而是创建了一套系统，使用基于pattern的设计，永远参考同一个参照时间：MonJan:04:05MST。组成这个单一参照时间的元素，可以重新组合成任何一种你可能遇到的格式。你可以在这里（原文没有链接，疑似这里）找到准确，完整的说明。
当然，Golang的date解析也不那么完美，是吧？嗯，当然。你至少要考虑一个问题：timezone，否则不能重新解析date。除此之外，安排会议也大不可能了，还是因为Golang里的timezone，让类似“/10/:07:22America/New_York”这样的解析比较困难。“America/New_York”这几个bit（解析起来）比较麻烦。有一些变通的解决办法，不过Golang在解析timezone这部分还需要改进。
Golang之弊:函数重载
我想起上计算机科学课时候的事，第一感觉就是“太酷了！”，但是在Golang里完全不存在这种“酷”。以下来自GolangFAQ：
为什么Go不支持方法和操作符重载？如果不用做类型匹配，方法调度过程也会简化。使用其他语言的经验告诉我们，一些有着同名但不同签名的函数有时候很有用，不过实际使用中也会造成误解，不够健壮。Go类型系统主要使用的简化决策是只通过函数名匹配，并且要求类型的一致性。就操作符的重载来说，似乎比绝对要求（类型一致性）方便。不过还是，没有重载会更简单。
当然，没有方法重载确实更简单。但这样也会强制你想出唯一的函数名以防出现同名函数，这样一来就增大了你的代码量。如果你只是想复制粘贴下代码，“以后再解”，还要记住共用函数是在私有的还是公共函数起作用。后面提到的time包有几个这样的实例，我们特别想用一个默认值替代最后那个可选参数。
1funcParse(layout,valuestring)(Time,error){2returnparse(layout,value,UTC,Local)3}45funcParseInLocation(layout,valuestring,loc*Location)(Time,error){6returnparse(layout,value,loc,loc)7}89funcparse(layout,valuestring,defaultLocation,local*Location)(Time,error){10...11}[源代码地址]
这就是说，没有方法重载绝不妨碍使用Golang。在几个我想用（重载）的实例中，我最终只用了一个共用的私有函数，和其它几个不同名字的函数，或是删除了我一开始说需要重载的原因。
每隔一周左右，我们会发布一篇新指南，和本篇一样都在“Golang之于DevOps开发的利与弊”六部曲中。：#5：跨平台编译，Windows，Signals，Docs和编译器。
现在起订阅我们的博客吧，这样你就不会错过我们的文章发布了，如果你觉得你的开发者朋友们能受益于了解Golang的利与弊，请把这篇博文分享给他们，尤其是有关DevOps生命周期的。感谢您阅读和分享。
via:
转载请注明：http://www.0431gb208.com/sjslczl/5195.html
