Go Modules - соглашение об именах каталогов и пакетов
Я понимаю, что Go-модули все еще являются экспериментальной функцией подписки, и, возможно, из-за этого я не могу найти четкого руководства о том, как называть каталоги и package
s.
В этих именах пакетов в сообщении Go Blog и имени пакета в Effective Go они говорят о том, что каталог должен соответствовать имени пакета - но я не был уверен, будет ли Go Modules следовать той же схеме.
Если я хочу связать свою бизнес-логику в package business
со многими файлами, разумно ли создать подкаталог validators/
и сохранить то же имя пакета package business
?
someDir
├── business
│ ├── businessA.go // package business
│ ├── businessB.go // package business
│ ├── businessC.go // package business
│ ├── go.mod // module example.com/business
│ └── validators
│ ├── businessValidatorX.go // package business, or validators?
│ ├── businessValidatorY.go // package business, or validators?
│ └── businessValidatorZ.go // package business, or validators?
└── main.go
Подход 1.
Если бы я пошел с тем же именем пакета:
// main.go
package main
import (
"example.com/business"
"example.com/business/validators"
)
// both imports would be combined to the same `business` package?
func main() {
b := business.SomeLogic()
business.ValidateX(b) // validator from the same package
}
Это выглядит склонным к конфликту экспорта - но это просто.
Подход 2.
Если validators/
карты путей к package validators
, код потребления будет выглядеть как показано ниже.
// main.go
package main
import (
"example.com/business"
"example.com/business/validators"
)
func main() {
b := business.SomeLogic()
validators.ValidateX(b) // validator from a separate package
}
Как мне управлять пакетом, состоящим из множества файлов? Является ли подход 1. разумным, хотя он несколько противоречит вышеприведенному посту и документу?
Или я должен пойти с подходом 2., в соответствии с соглашением, и добавить псевдоним по мере необходимости в main.go
?
1 ответ
Подход 2 правильный.
Будучи новичком в Go, я по ошибке подумал, что подход 1 - это один из возможных способов, поскольку Go позволяет использовать имя пакета, отличное от имени каталога.
Как помог Volker в комментариях, Подход 1 определенно невозможен.
Вы получите прямую ошибку компиляции при попытке объединить пакеты.
Внедрение модулей Go не влияет на лучшие практики, изложенные в существующих документах, такие как:
Как примечание, я также узнал, что имя пакета должно быть в единственном числе.
Так что это оставило бы меня со следующей структурой вместе с подходом 2: