最近在對之前的代碼做重構，從之前的 MVC 結構切換到 Clean Arch 的結構，但是在切換的時候關于代碼風格出現了一些困惑。

在下面的代碼中 repository 是存儲庫，主要用于封裝數據庫查詢或者是第三方微服務的調用，它實現了 domain.IAzRepository 接口，其他層的代碼都只依賴這個接口而不依賴具體的實現

[[353658]]

三種代碼風格

風格一

在 Go 中我們常常“返回實現(struct)，依賴接口”，其實就是在函數返回的時候我們返回一個具體的實現，函數的參數或者是 Struct 的成員部分我們依賴接口，這個風格看起來是違背了這個原則的

// repository 存儲庫 
type repository struct { 
    db *gorm.DB 
} 
 
// NewAZRepository NewAZRepository 
func NewAZRepository(db *gorm.DB) domain.IAzRepository { 
    return &repository{db: db} 
} 

風格二

這個風格返回了實現，并且由于并沒有導出看起來也具有封裝的特性，但是如果你運行 golint 你就會發現會拋出錯誤，因為這么寫，會導致我們用導出的方法將沒有導出 struct 給暴露了出去

// repository 存儲庫 
type repository struct { 
    db *gorm.DB 
} 
 
// NewAZRepository NewAZRepository 
func NewAZRepository(db *gorm.DB) *repository { 
    return &repository{db: db} 
} 

風格三

這個寫法的主要問題是，由于 Repository 被導出，所以在外部其他的包中就可以直接通過 &Repository{} 進行初始化，這樣初始化之后使用就會導致 panic，因為成員函數是一個 nil 指針

// Repository 存儲庫 
type Repository struct { 
    db *gorm.DB 
} 
 
// NewAZRepository NewAZRepository 
func NewAZRepository(db *gorm.DB) *Repository { 
    return &Repository{db: db} 
} 

選擇

選擇總是困難的，帶著這個問題我咨詢了同組的同事還有好幾個 Go 語言交流群的同學，其中大部分都會選擇風格三，小部分會選擇風格一，風格二幾乎沒有人選擇。最后我選什么呢?

最后我的選擇是風格一，這是針對場景來的，因為我們的這個包其實不希望其他包直接依賴實現，因為后續有可能隨著發展被單獨拆分成一個微服務或者是需要更換存儲庫，如果外部有包直接依賴 repository 會導致后續的重構比較困難

除此之外，我們在其他地方一般還是會選擇風格三，因為結構體名不導出，外部其實沒有比較好的辦法進行初始化，例如想要 var r Repository ，至于前面提到的直接字面量初始化的問題，我們可以通過統一代碼風格解決。

在 外部包 中除了用于參數傳遞的 Option 結構之外，其余的不允許直接通過 &XXX{} 的方式進行初始化