Это очень похоже на шаблон - кроме динамического импорта. Он называется «Интерфейсы» .
Учитывая определение интерфейса как
type Stringer interface{
String() string
}
и тип Foo, реализующий указанный интерфейс
type foo int
func(f foo)String() string{
return fmt.Sprintf(”%d”,f)
}
, а также Bar, реализующий указанный интерфейс
type bar string
func (b bar) String()string {
return string(b)
}
Фактически можно использовать оба в качестве параметра для функции baz
func baz(s Stringer){
fmt.Println(s.String())
}
Обратите внимание, что в отличие от других языков, вам не нужно объявлять интерфейсы, которые реализует тип, - если тип фактически реализует интерфейс, компилятор go с ним согласен. Бег на детской площадке
Итак, что касается вашего вопроса об импорте пакетов: если у вас нет огромных деревьев зависимостей для импорта, это действительно не стоит хлопот.
Допустим, мы говорим о приложении, использующем либо BBolt, либо etcd, а в качестве примера - MongoDB. Результирующий размер, включающий всех из них, хотя, говоря относительно, весьма удивителен, незначителен. Я скомпилировал программу go с импортом bbolt, bbolt & etcd и bbolt, etcd & mongodb. Это результаты в байтах.
11734884 size_all
2455544 size_bolt
10307700 size_boltetcd
Мы говорим о нескольких мегабайтах в размере файла. Допустим, вы используете либо Bolt , либо etcd , либо MongoDB, хотите ли вы действительно прыгать через все обручи и циклы, необходимые для правильного выполнения динамического импорта? Я, со своей стороны, не хотел бы этого делать и не хотел бы, чтобы Go предоставил такую функцию.
«Преждевременная оптимизация - корень всего зла (или, по крайней мере, большей его части) в программировании».
& Ndash; Дональд Кнут