建站
咨詢
售后
建站咨詢
新聞中心
go語言適合做什么？
Go語言。他主要是在一些網(wǎng)頁版的服務(wù)器中用于系統(tǒng)編程的一種語言。他是谷歌開發(fā)的一種編程語言。在一定程度上，谷歌有一定的壟斷作用。不能隨隨便便的在語言當中添加其他的語言成分。
創(chuàng)新互聯(lián)致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營銷，包括成都網(wǎng)站制作、網(wǎng)站建設(shè)、SEO優(yōu)化、網(wǎng)絡(luò)推廣、整站優(yōu)化營銷策劃推廣、電子商務(wù)、移動互聯(lián)網(wǎng)營銷等。創(chuàng)新互聯(lián)為不同類型的客戶提供良好的互聯(lián)網(wǎng)應用定制及解決方案，創(chuàng)新互聯(lián)核心團隊十年專注互聯(lián)網(wǎng)開發(fā)，積累了豐富的網(wǎng)站經(jīng)驗，為廣大企業(yè)客戶提供一站式企業(yè)網(wǎng)站建設(shè)服務(wù)，在網(wǎng)站建設(shè)行業(yè)內(nèi)樹立了良好口碑。
Go語言實踐模式 - 函數(shù)選項模式(Functional Options Pattern)
大家好，我是小白，有點黑的那個白。
最近遇到一個問題，因為業(yè)務(wù)需求，需要對接第三方平臺.
而三方平臺提供的一些HTTP(S)接口都有統(tǒng)一的密鑰生成規(guī)則要求.
為此我們封裝了一個獨立的包 xxx-go-sdk 以便維護和對接使用.
其中核心的部分是自定義HTTP Client,如下:
一些平臺會要求appKey/appSecret等信息，所以Client結(jié)構(gòu)體就變成了這樣，這時參數(shù)還比較少, 而且是必填的參數(shù)，我們可以提供構(gòu)造函數(shù)來明確指定。
看起來很滿足，但是當我們需要增加一個 Timeout 參數(shù)來控制超時呢?
或許你會說這還不簡單，像下面一樣再加一個參數(shù)唄
那再加些其他的參數(shù)呢？那構(gòu)造函數(shù)的參數(shù)是不是又長又串，而且每個參數(shù)不一定是必須的，有些參數(shù)我們又會考慮默認值的問題。
為此，勤勞但尚未致富的 gophers 們使用了總結(jié)一種實踐模式
首先提取所有需要的參數(shù)到一個獨立的結(jié)構(gòu)體 Options，當然你也可以用 Configs 啥的.
然后為每個參數(shù)提供設(shè)置函數(shù)
這樣我們就為每個參數(shù)設(shè)置了獨立的設(shè)置函數(shù)。返回值 func(*Options) 看著有點不友好，我們提取下定義為單個 Option 調(diào)整一下代碼
當我們需要添加更多的參數(shù)時，只需要在 Options 添加新的參數(shù)并添加新參數(shù)的設(shè)置函數(shù)即可。
比如現(xiàn)在要添加新的參數(shù) Timeout
這樣后續(xù)不管新增多少參數(shù)，只需要新增配置項并添加獨立的設(shè)置函數(shù)即可輕松擴展，并且不會影響原有函數(shù)的參數(shù)順序和個數(shù)位置等。
至此，每個選項是區(qū)分開來了，那么怎么作用到我們的 Client 結(jié)構(gòu)體上呢?
首先，配置選項都被提取到了 Options 結(jié)構(gòu)體重，所以我們需要調(diào)整一下 Client 結(jié)構(gòu)體的參數(shù)
其次，每一個選項函數(shù)返回 Option,那么任意多個就是 ...Option，我們調(diào)整一下構(gòu)造函數(shù) NewClient 的參數(shù)形式，改為可變參數(shù)，不再局限于固定順序的幾個參數(shù)。
然后循環(huán)遍歷每個選項函數(shù)，來生成Client結(jié)構(gòu)體的完整配置選項。
那么怎么調(diào)用呢？對于調(diào)用方而已，直接在調(diào)用構(gòu)造函數(shù)NewClient()的參數(shù)內(nèi)添加自己需要的設(shè)置函數(shù)(WithXXX)即可
當需要設(shè)置超時參數(shù)，直接添加 WithTimeout即可,比如設(shè)置3秒的超時
配置選項的位置可以任意設(shè)置，不需要受常規(guī)的固定參數(shù)順序約束。
可以看到，這種實踐模式主要作用于配置選項，利用函數(shù)支持的特性來實現(xiàn)的，為此得名 Functional Options Pattern，優(yōu)美的中國話叫做「函數(shù)選項模式」。
最后, 我們總結(jié)回顧一下在Go語言中函數(shù)選項模式的優(yōu)缺點
如何看待go語言泛型的最新設(shè)計？
Go 由于不支持泛型而臭名昭著，但最近，泛型已接近成為現(xiàn)實。Go 團隊實施了一個看起來比較穩(wěn)定的設(shè)計草案，并且正以源到源翻譯器原型的形式獲得關(guān)注。本文講述的是泛型的最新設(shè)計，以及如何自己嘗試泛型。
例子
FIFO Stack
假設(shè)你要創(chuàng)建一個先進先出堆棧。沒有泛型，你可能會這樣實現(xiàn)：
type?Stack?[]interface{}func?(s?Stack)?Peek()?interface{}?{
return?s[len(s)-1]
}
func?(s?*Stack)?Pop()?{
*s?=?(*s)[:
len(*s)-1]
}
func?(s?*Stack)?Push(value?interface{})?{
*s?=?
append(*s,?value)
}
但是，這里存在一個問題：每當你 Peek 項時，都必須使用類型斷言將其從 interface{} 轉(zhuǎn)換為你需要的類型。如果你的堆棧是 *MyObject 的堆棧，則意味著很多 s.Peek().(*MyObject)這樣的代碼。這不僅讓人眼花繚亂，而且還可能引發(fā)錯誤。比如忘記 * 怎么辦？或者如果您輸入錯誤的類型怎么辦？s.Push(MyObject{})` 可以順利編譯，而且你可能不會發(fā)現(xiàn)到自己的錯誤，直到它影響到你的整個服務(wù)為止。
通常，使用 interface{} 是相對危險的。使用更多受限制的類型總是更安全，因為可以在編譯時而不是運行時發(fā)現(xiàn)問題。
泛型通過允許類型具有類型參數(shù)來解決此問題：
type?Stack(type?T)?[]Tfunc?(s?Stack(T))?Peek()?T?{
return?s[len(s)-1]
}
func?(s?*Stack(T))?Pop()?{
*s?=?(*s)[:
len(*s)-1]
}
func?(s?*Stack(T))?Push(value?T)?{
*s?=?
append(*s,?value)
}
這會向 Stack 添加一個類型參數(shù)，從而完全不需要 interface{}?，F(xiàn)在，當你使用 Peek() 時，返回的值已經(jīng)是原始類型，并且沒有機會返回錯誤的值類型。這種方式更安全，更容易使用。（譯注：就是看起來更丑陋，^-^）
此外，泛型代碼通常更易于編譯器優(yōu)化，從而獲得更好的性能（以二進制大小為代價）。如果我們對上面的非泛型代碼和泛型代碼進行基準測試，我們可以看到區(qū)別：
type?MyObject?struct?{
X?
int
}
var?sink?MyObjectfunc?BenchmarkGo1(b?*testing.B)?{
for?i?:=?0;?i??b.N;?i++?{
var?s?Stack
s.Push(MyObject{})
s.Push(MyObject{})
s.Pop()
sink?=?s.Peek().(MyObject)
}
}
func?BenchmarkGo2(b?*testing.B)?{
for?i?:=?0;?i??b.N;?i++?{
var?s?Stack(MyObject)
s.Push(MyObject{})
s.Push(MyObject{})
s.Pop()
sink?=?s.Peek()
}
}
結(jié)果：
BenchmarkGo1BenchmarkGo1-16?????12837528?????????87.0?ns/op???????48?B/op????????2?allocs/opBenchmarkGo2BenchmarkGo2-16?????28406479?????????41.9?ns/op???????24?B/op????????2?allocs/op
在這種情況下，我們分配更少的內(nèi)存，同時泛型的速度是非泛型的兩倍。
合約（Contracts）
上面的堆棧示例適用于任何類型。但是，在許多情況下，你需要編寫僅適用于具有某些特征的類型的代碼。例如，你可能希望堆棧要求類型實現(xiàn) String() 函數(shù)
Go語言設(shè)計與實現(xiàn)（上）
基本設(shè)計思路：
類型轉(zhuǎn)換、類型斷言、動態(tài)派發(fā)。iface，eface。
反射對象具有的方法：
編譯優(yōu)化：
內(nèi)部實現(xiàn)：
實現(xiàn) Context 接口有以下幾個類型（空實現(xiàn)就忽略了）：
互斥鎖的控制邏輯：
設(shè)計思路：
（以上為寫被讀阻塞，下面是讀被寫阻塞）
總結(jié)，讀寫鎖的設(shè)計還是非常巧妙的：
設(shè)計思路：
WaitGroup 有三個暴露的函數(shù):
部件：
設(shè)計思路：
結(jié)構(gòu)：
Once 只暴露了一個方法：
實現(xiàn)：
三個關(guān)鍵點：
細節(jié)：
讓多協(xié)程任務(wù)的開始執(zhí)行時間可控（按順序或歸一）。（Context 是控制結(jié)束時間）
設(shè)計思路： 通過一個鎖和內(nèi)置的 notifyList 隊列實現(xiàn)，Wait() 會生成票據(jù)，并將等待協(xié)程信息加入鏈表中，等待控制協(xié)程中發(fā)送信號通知一個（Signal()）或所有（Boardcast()）等待者（內(nèi)部實現(xiàn)是通過票據(jù)通知的）來控制協(xié)程解除阻塞。
暴露四個函數(shù)：
實現(xiàn)細節(jié)：
部件：
包： golang.org/x/sync/errgroup
作用：開啟 func() error 函數(shù)簽名的協(xié)程，在同 Group 下協(xié)程并發(fā)執(zhí)行過程并收集首次 err 錯誤。通過 Context 的傳入，還可以控制在首次 err 出現(xiàn)時就終止組內(nèi)各協(xié)程。
設(shè)計思路：
結(jié)構(gòu)：
暴露的方法：
實現(xiàn)細節(jié)：
注意問題：
包： "golang.org/x/sync/semaphore"
作用：排隊借資源（如錢，有借有還）的一種場景。此包相當于對底層信號量的一種暴露。
設(shè)計思路：有一定數(shù)量的資源 Weight，每一個 waiter 攜帶一個 channel 和要借的數(shù)量 n。通過隊列排隊執(zhí)行借貸。
結(jié)構(gòu)：
暴露方法：
細節(jié)：
部件：
細節(jié)：
包： "golang.org/x/sync/singleflight"
作用：防擊穿。瞬時的相同請求只調(diào)用一次，response 被所有相同請求共享。
設(shè)計思路：按請求的 key 分組（一個 *call 是一個組，用 map 映射存儲組），每個組只進行一次訪問，組內(nèi)每個協(xié)程會獲得對應結(jié)果的一個拷貝。
結(jié)構(gòu)：
邏輯：
細節(jié)：
部件：
如有錯誤，請批評指正。
本文名稱：go語言模式設(shè)計 go語言設(shè)計者
網(wǎng)頁地址：http://www.dlmjj.cn/article/ddjdigg.html
