導讀?

最近要封裝一個公共服務，涉及到配置項的地方總是找不到合理的方案，后來看了一下grpc在配置方面的封裝，了解到原來是golang特有的Functional Options編程模式，今天分享給大家，希望你能用到，咱們直接來看代碼

版本V1

上面代碼很容易，就是想初始化一下Server的配置選項，看起來好像沒什么問題，其實問題非常多

• 既然是初始化一些配置選項，那么當然是有的是必選項(Addr, Port)，有的是可選項(Timeout,MaxConns),可選項不選的話還得給個默認值，顯然這種方式是不滿足的
• 因為Server的屬性都是公有方法，所以在外部任何地方都能修改屬性，存在很嚴重的代碼安全隱患
• 上面Server和main函數雖然在同一個文件里面，其實Server是作為外部包使用的，下面的case都同理 既然上面無法滿足咱們的需求，那么咱們就來修改一下

版本V2

既然配置項想要可選，那么咱們直接來個排列組合，調用不同的初始化方法即可只初始化自己想初始化的非必要選項

• Server的屬性都是私有變量，的確是解決了包的屬性被惡意篡改的行為，降低了代碼風險
• 但是排列組合太多，新增一個屬性得新增指數級的方法，我上面的demo可選參數只有兩個timeout和maxConns，但是如果有十幾個可選參數，那么需要構造的初始化方法是非常多的
• 一般情況下，對一個工具初始化都是統一的方法，這樣處理的話初始化方法太多了，這一塊的內容對使用者來說是不關心的，所以很不友好
• 不想傳的參數的默認值依然沒有解決

版本V3

既然上面的例子封裝的初始化方法太多，那么咱們就統一用一個方法來解決

• 這樣做的確是解決了初始化方法太多的問題，但是太不靈活
• 比如有100個可選參數，那而且你只想給最后一個可選參數賦值，但是前面99個你也得寫，寫的話具體寫幾？我既然不關心前面99個可選參數，但是為什么還要寫呢？這給人感覺就很奇怪

版本V4

咱們引入一個新的結構體Config，把必填的參數放在server里面，非必要的參數放在Congfig里面

• 解決了非必要參數可以有選擇性的傳一部分的問題，比如上面的case種只需要傳Timeout
• 也解決了不傳的參數，能有默認值的問題，比如MaxConns不傳的話 就是10
• 但是如果只傳必傳的參數，那么在NewDefaultServer的時候，最后一個參數只能傳nil，傳nil的情況是不允許的，也是不友好的。
• 用這種方式的話，Config的屬性必須是公共變量，當然就有在運行的過程中屬性被篡改的風險

版本V5

咱們來學一學java中的builder模式

• 其實就是在Server對象外部包了一層ServerBuilder，最后在ServerBuilder.Build()中返回了Server對象
• 其實這個方法挺完美，滿足了我們之前提的全部需求，但是問題在于，golang中的err處理，在這種方式中不是很好體現

版本V6

接下來咱們就看一看最后的終極解決方案 FUNCTIONAL OPTIONS模式

• 這個需要注意的是  type Option func(*Server)
• 這個看起來比較整潔和優雅，對外的接口只有一個Create。
• 相比于Builder模式，不需要引入一個Builder對象。
• 對比配置化的模式，也不需要引入一個新的Config。

總結?

Golang 由于語言本身的特性，不支持函數重載，函數式選項 的編程模式在一定程度上解決了其他語言需要通過函數重載解決的問題。函數式選項 編程有以下優點：

• 任意順序傳遞參數
• 支持默認值
• 向后兼容性
• 很容易維護和擴展

雖然 函數式選項 編程模式有很多優點，但是設計模式的存在都是為了彌補語言特性的缺陷的一種手段。它是為了解決代碼擴展性的問題，往往是通過增加抽象犧牲了簡單性，切勿過度使用。有些簡單的配置，就不需要設計的這么通用了。

函數式選項模式的使用場景有哪些呢：

我們一般用來配置一些基礎的服務配置，比如MySQL，Redis，Kafka的配置，很多可選參數，可以方便動態靈活的配置想要配置的參數。