最近在對(duì)之前的代碼做重構(gòu)，從之前的 MVC 結(jié)構(gòu)切換到 Clean Arch 的結(jié)構(gòu)，但是在切換的時(shí)候關(guān)于代碼風(fēng)格出現(xiàn)了一些困惑。

在下面的代碼中 repository 是存儲(chǔ)庫，主要用于封裝數(shù)據(jù)庫查詢或者是第三方微服務(wù)的調(diào)用，它實(shí)現(xiàn)了 domain.IAzRepository 接口，其他層的代碼都只依賴這個(gè)接口而不依賴具體的實(shí)現(xiàn)

[[353658]]

三種代碼風(fēng)格

風(fēng)格一

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

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

風(fēng)格二

這個(gè)風(fēng)格返回了實(shí)現(xiàn)，并且由于并沒有導(dǎo)出看起來也具有封裝的特性，但是如果你運(yùn)行 golint 你就會(huì)發(fā)現(xiàn)會(huì)拋出錯(cuò)誤，因?yàn)檫@么寫，會(huì)導(dǎo)致我們用導(dǎo)出的方法將沒有導(dǎo)出 struct 給暴露了出去

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

風(fēng)格三

這個(gè)寫法的主要問題是，由于 Repository 被導(dǎo)出，所以在外部其他的包中就可以直接通過 &Repository{} 進(jìn)行初始化，這樣初始化之后使用就會(huì)導(dǎo)致 panic，因?yàn)槌蓡T函數(shù)是一個(gè) nil 指針

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

選擇

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

最后我的選擇是風(fēng)格一，這是針對(duì)場景來的，因?yàn)槲覀兊倪@個(gè)包其實(shí)不希望其他包直接依賴實(shí)現(xiàn)，因?yàn)楹罄m(xù)有可能隨著發(fā)展被單獨(dú)拆分成一個(gè)微服務(wù)或者是需要更換存儲(chǔ)庫，如果外部有包直接依賴 repository 會(huì)導(dǎo)致后續(xù)的重構(gòu)比較困難

除此之外，我們?cè)谄渌胤揭话氵€是會(huì)選擇風(fēng)格三，因?yàn)榻Y(jié)構(gòu)體名不導(dǎo)出，外部其實(shí)沒有比較好的辦法進(jìn)行初始化，例如想要 var r Repository ，至于前面提到的直接字面量初始化的問題，我們可以通過統(tǒng)一代碼風(fēng)格解決。

在 外部包 中除了用于參數(shù)傳遞的 Option 結(jié)構(gòu)之外，其余的不允許直接通過 &XXX{} 的方式進(jìn)行初始化