Нарушает ли "Прием интерфейсов" инструменты устаревания?

Question 1

Осуждение

Поддерживаемый способ маркировки функций как устаревших выглядит примерно так:

type MyStruct struct {
}

// MyFunc returns hello
// Deprecated: Use YourFunc
func (m MyStruct) MyFunc() string {
  return "hello"
}

Современные IDE будут выделять любое использование этой функции, а линтеры также могут вызывать предупреждения (я лично не проверял это).

Принимайте интерфейсы. Возвращаемые структуры.

Популярная лучшая практика - "Принимать интерфейсы. Возвращаемые структуры". - что, как правило, поощряет НАДЕЖНЫЙ дизайн в программном обеспечении.

Однако следующий код, который следует этой наилучшей практике, скрывает предупреждение об устаревании:


// MyInterface specifies a single function that we require from a dependency
type MyInterface interface {
    MyFunc() string
}

func main() {

    var v MyInterface
    v = MyStruct{}
    v.MyFunc()

}

Вопрос

Есть ли решение этой проблемы?

Если бы я был, например, сопровождающим библиотеки: как я могу гарантировать, что мои предупреждения об устаревании будут видны пользователям библиотеки, которые также следуют рекомендациям и определяют свои собственные интерфейсы зависимостей.

Question 2

Это кажется логичным, поскольку метод интерфейса не был устаревшим. Добавление Deprecated: строка функции интерфейса может помочь в этом случае (не тестировал, так как VSCode этого еще не делает).

// MyInterface specifies a single function that we require from a dependency
type MyInterface interface {
    // Deprecated: use YourFunc
    MyFunc() string
}

В этом случае, поскольку интерфейс имеет только 1 функцию, вы должны отказаться от всего этого. Который, как я знаю, поддерживается godoc/pkg.go.dev, возьмем, к примеру, Queryer.

// MyInterface specifies a single function that we require from a dependency
// Deprecated: use YourInterface
type MyInterface interface {
    MyFunc() string
}

caveman · Answer 1 · 2021-11-22T21:18:36

3

Это кажется логичным, поскольку метод интерфейса не был устаревшим. Добавление Deprecated: строка функции интерфейса может помочь в этом случае (не тестировал, так как VSCode этого еще не делает).

// MyInterface specifies a single function that we require from a dependency
type MyInterface interface {
    // Deprecated: use YourFunc
    MyFunc() string
}

В этом случае, поскольку интерфейс имеет только 1 функцию, вы должны отказаться от всего этого. Который, как я знаю, поддерживается godoc/pkg.go.dev, возьмем, к примеру, Queryer.

// MyInterface specifies a single function that we require from a dependency
// Deprecated: use YourInterface
type MyInterface interface {
    MyFunc() string
}

caveman

2021-11-22 21:18:36

Однако один из основных аспектов вопроса заключается в следующем: "Как сопровождающий библиотеки, как я могу гарантировать, что мое уведомление об устаревании будет замечено конечными пользователями?" Сопровождающий библиотеки не контролирует определения пользовательского интерфейса, поэтому он не может войти в систему и добавить туда предупреждения об устаревании.

Brad Johnson

Мне кажется странным, что библиотека предоставляет структуру, а пользователь предоставляет интерфейс, который реализует структура библиотеки. Если это сценарий, о котором вы беспокоитесь, было бы разумнее отказаться от всей вашей структуры, что должно привести к v = MyStruct{} чтобы стать пораженным через

caveman

"Мне кажется странным, что библиотека предоставляет структуру, а пользователь предоставляет интерфейс..." Разве не это поощряет принцип разделения интерфейсов?

Brad Johnson

Насколько я знаю, принцип разделения интерфейсов заключается в разбиении больших интерфейсов на более мелкие межпространства, подобно тому, как "Чем больше интерфейс, тем слабее абстракция". иди пословицей. Я думаю, что здесь больше действует принцип инверсии зависимостей. Обычно вы хотите использовать интерфейсы в качестве параметров, чтобы можно было заменить фактическую реализацию. Поэтому логично определить интерфейс в пакете и использовать его в качестве входных данных. Но я не знаю ни одного распространенного случая использования, когда пользователь пакета определяет интерфейс, который неявно реализует структура библиотеки.

caveman

Нарушает ли "Прием интерфейсов" инструменты устаревания?

Вопрос

Осуждение

Принимайте интерфейсы. Возвращаемые структуры.

Вопрос

Лучший ответ

На других языках

Эта страница на других языках

Популярное в этой категории

Популярные вопросы в этой категории