“接受接口”是不是会破坏弃用工具？

Posted 2023-03-29

【中文标题】“接受接口”是不是会破坏弃用工具？

【英文标题】：Does "Accept Interfaces" break deprecation tooling?“接受接口”是否会破坏弃用工具？

【发布时间】：2022-01-01 10:04:25

【问题描述】：

弃用

支持将函数标记为已弃用的方式如下：

type MyStruct struct 


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

现代 IDE 会突出显示此函数的任何用法，并且 linter 也可能会发出警告（我没有亲自检查过）

接受接口。返回结构。

一个流行的最佳实践是“接受接口。返回结构”。 - 这往往会鼓励软件中的 SOLID 设计。

但是，以下代码（遵循此最佳实践）隐藏了弃用警告：

// 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()

问题

这个问题有解决办法吗？

例如，如果我是库维护者：我如何确保库用户看到我的弃用警告，他们也遵循最佳实践并定义自己的依赖项接口。

【参考方案1】：

这似乎是合乎逻辑的，因为接口的方法尚未被弃用。在这种情况下，将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

【讨论】：

然而，问题的核心方面之一是“作为库维护者，我如何确保最终用户看到我的弃用通知？”库维护者无法控制用户的界面定义，因此他们无法进入并在那里添加弃用警告。

库提供结构而用户提供库的结构实现的接口对我来说似乎很奇怪。如果这是您担心的情况，那么弃用整个结构会更明智，这应该会导致 v = MyStruct 被击穿

“库提供结构而用户提供接口对我来说似乎很奇怪......”这不是接口隔离原则所鼓励的吗？

据我所知，接口分离原则是将大接口分解成更小的接口，就像“接口越大，抽象越弱”。去谚语。我认为依赖倒置原则在这里发挥更大的作用。您通常希望将接口用作参数，以便可以换出实际的实现。因此在包中定义一个接口并将其用作输入是合乎逻辑的。但我不知道任何常见的用例，其中包的用户定义了库结构隐式实现的接口。