引言

在 Go 語言中，我們一般會用模塊（Module）和包（Package）來組織我們的項(xiàng)目、庫的目錄和代碼結(jié)構(gòu)。

今天給大家分享一個(gè)面向包這塊的新提案，看看是否合適加進(jìn) Go 特性中？

前置知識：模塊和包

具體來講，模塊（Module）就是 go mod 的應(yīng)用。我們最常接觸到的是以下命令：

mkdir my-project
cd my-project
go mod init github.com/eddycjjy/my-project

在執(zhí)行了 go mod init 后會生成 go.mod 文件，如下所示：

// go.mod
module github.com/eddycjy/my-project

go 1.21.1

這就是這個(gè)項(xiàng)目的模塊。

對應(yīng)到包（Package）中，會更加的直接和顯性。我們一般會創(chuàng)建類似如下的目錄結(jié)構(gòu)：

<my-project>
  -<cli>
    --cli.go
  -<internals>
    --internals.go
  --go.mod
  --main.go

Go 文件中的 package name，存在明確的約定俗成的標(biāo)準(zhǔn)，需要和目錄名稱保持一致。例如：

// internals.go
package internals
import "fmt"
func Hello() {
 fmt.Println("你好，煎魚！")
}

如果在其他地方中導(dǎo)入該包，則為：

import (
 ...
 "github.com/eddycjy/my-project/internals"
)

以上就是模塊和包的基礎(chǔ)前置知識。我們接下來正式進(jìn)入提案的正題。

提案：透明文件夾

針對 Go 程序的組織結(jié)構(gòu)管理，最近社區(qū)有個(gè)同學(xué)提出了一個(gè)新提案：

在 Go 里文件夾默認(rèn)與包（Package）的關(guān)系是劃等號的。雖然這很方便，但是提案作者反饋：在某些情況下，我們需要通過文件夾來實(shí)現(xiàn)純粹的組織和可讀性目的，而不想引入新的包。

為此提出了 “透明文件夾” 的概念，通過使用諸如 Next.js 應(yīng)用程序路由器中看到的 (folder) 或 _folder 之類的語義來表示。

這些文件夾可以在不創(chuàng)建新軟件包的情況下組織軟件包內(nèi)的文件。它們將與軟件包的根目錄保持鏈接。

例子如下：

myapp
  main.go
  myTypes.go
  (routes)
     handleRoot.go
     handleMultipart.go
     ...
  db
     connect.go
     dbTypes.go
     (auth)
         strategy1.go
         strategy2.go
         ...

可以看到這個(gè)例子，他使用 (folder) 的方式來表示透明文件夾。例如：(routes) 和 (auth)，這樣他就不需要再細(xì)分不同的 package name，統(tǒng)一用 myapp 和 db 的包名就能進(jìn)行引用。

簡單來講，該提案的實(shí)現(xiàn)方式是：通過將工程中 package name 和實(shí)體文件夾目錄的作用分割開，目的是：提供一種純粹的代碼組織方式。

一些爭議

其實(shí)類似的場景訴求，我有一個(gè)朋友曾經(jīng)聽幾個(gè)同事吐槽過。但一般會是在比較大的 Go 項(xiàng)目中，例如出現(xiàn)以下場景：

myapp
  service
    a-service
    b-service
    c-service
    ...

會認(rèn)為這樣 package 切割的比較碎，但是不區(qū)分開。多了后在代碼結(jié)構(gòu)上又很容易繁雜化。所以會想有一種純碎的代碼組織方式。

爭議也是有不少的。因?yàn)樗麑φZ言的 ROI 并不是太高，變動的東西（例如：工具、IDE、tests 等）會比較多。

只需將文件命名為：aaa-foo.go aaa-bar.go bbb-foo.go bbb-bar.go，而不是 aaa/foo.go aaa/bar.go bbb/foo.go bbb/bar.go。也能達(dá)到類似的效果。

也有表示添加透明子文件夾會讓一切變得更加復(fù)雜，卻沒有任何好處。把文件放在它們應(yīng)該在的地方就可以了?，F(xiàn)在已經(jīng)在其他語言中看到過這種替代方法，很糟糕。

總結(jié)

這個(gè)提案本身的出發(fā)點(diǎn)很常見，因?yàn)?package name 和代碼目錄結(jié)構(gòu)綁定了，會導(dǎo)致在設(shè)計(jì)代碼結(jié)構(gòu)時(shí)會有些受限，最終受此引導(dǎo)拆 package 來形成結(jié)構(gòu)化。

如果盲目的添加透明文件夾，反而會出現(xiàn)一個(gè)尷尬的問題。因?yàn)?Go 語言在這塊是非常直接的，添加了這類模式，大家反而會沒法篤定，要去看看項(xiàng)目的代碼結(jié)構(gòu)才能確定。

以上就是Go 面向包新提案透明文件夾必要性分析的詳細(xì)內(nèi)容，更多關(guān)于Go 透明文件夾的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論