Go 編程：記一次函數定義的爭論

原文連接：www.gitdig.com/go-function…

最近和同事討論開發通用(基礎)包的事，討論半天，口乾舌燥，彷佛也沒有成功的將我的理念安利出去。只得將這些「自覺得是」的東西寫下來，供讀者參考。

爲了減小重複代碼和提高代碼的維護性，一般須要將此類功能代碼提煉出來，做爲一個通用(基礎)包加以實現。既然是一個通用(基礎)包，就必須定義一套通用函數，方便你們使用。那麼，如何定義這些函數就是成了本次爭論的焦點。

函數定義上的分歧

以本次爭論的例子來講明：

提供一個通用包，封裝redis庫的隊列功能。

在函數定義上咱們出現嚴重分歧.

個人函數定義：

func New(opts ...ClientOpt) *Client 複製代碼

他的函數定義：

func New(config redis.Option) *Client 複製代碼

在建立客戶對象的參數上，我認爲須要具體的將配置經過ClientOpt選項的方式，一個個具體定義出來。他則認爲，能夠直接傳遞redis.Option選項。他的理由很簡單：

• 這樣直接使用redis.Option選項配置能夠更加靈活
• 在基礎包的實現代碼上也簡單，不必每加一個配置就增長一個ClientOpt定義

我反駁他的理由以下：

• 直接使用redis.Option的話，那麼使用上，還必須引用redis包。這樣在我看來就打破了代碼組織上的分層原則。
• 直接使用redis.Option配置，看似靈活，其實增長了使用者誤用風險。之因此須要在redis包基礎上再封裝一層就是須要儘可能減小使用者出錯的可能性。若是須要靈活的話，徹底使用redis包就能夠了，根本不必作進一步的封裝。

他再反駁我：

• 使用ClientOpt選項配置，主次不清，使用者是並不知道什麼是必選，什麼是可選。

針對他的這個指控，我是接受的，從新修改了一下函數簽名, 將必選與可選分開，以下：

//address 做爲必選參數，直接顯示的進行定義
//options 可選參數
func New(address string, options ...ClientOpt) *Client 複製代碼

這樣定義以後，我想就能夠說服對方了，結果仍是高估了本身的說服能力。如今寫下來，也許更具備說服力一點。