Go 是一门新兴的语言，如果你正在使用它，很可能这不是你的第一门编程语言。
从不同的语言背景转来，你带来了自己的既有经验和范式。你在以前的语言中习惯做的事情，在 Go 中可能并不是一个好的方式。
学习 Go 不仅仅是学习一种新的语法。它还涉及到学习一种新的程序思维方式。
Go 创始人 Rob Pike 曾经说过：“Go 的接口并不是 Java 或 C# 接口的变种，而是更多。它们是大规模编程和适应性强的进化设计关键。”
图片
正确使用接口可以带来简单性、可读性和更灵活的代码设计。（不正确使用会带来新的灾难）
以下是建议了解的基本原则 TOP3:
拥有过多接口的情况叫做：接口污染。当你在编写具体类型之前就开始抽象时，就会出现这种情况。
由于无法预知需要哪些抽象，因此很容易编写出过多的接口，而这些接口在日后要么是错误的，要么是无用的。
Go 创始人给出了一个很棒的指导方针帮助我们避免接口污染。如下：
不要使用接口设计，而是发现它们（Don’t design with interfaces, discover them.） —— Rob Pike
Rob 在这里指出的是：你不需要提前考虑你需要什么抽象。你可以从具体的结构体开始设计，并在设计需要时只创建接口。通过这样做，你的代码会有机地增长到预期的设计。
但我仍然看到人们提前创建接口，因为他们认为他们将来可能需要多个实现。
对于他们，我要说：
图片
懒惰但要懒惰得好。创建接口的完美时机是当你真正需要它的时候，而不是当你预测你需要它的时候。
无用的接口往往只有一个实现。它们只是增加了一个额外的间接层，迫使程序员在他们实际上想要去实现时总是要通过这一层。
一个接口有一个成本：它是你在推理你的代码时需要记住的一个新概念。正如 Djikstra 所说，一个理想的接口必须是：“一个可以绝对精确的新语义层面。”
所以在创建接口之前问问自己：你有多个接口的实现吗？我强调了 “有”，因为 “将有” 意味着你可以预测未来，而你不能。
在 PHP 项目中看到 10 个方法的接口是很典型的。在 Go 中，接口很小，标准库中所有接口的平均方法数是 2。
“越大的接口抽象就越弱”，这是 Go 谚语之一。正如 Rob Pike 所说，这是关于接口最重要的事情，这意味着接口越小，它就越有用。
一个接口可以有的实现越多，它就越通用。如果你有一个包含大量方法的接口，就很难有多个实现。
你拥有的方法越多，接口就越具体。接口越具体，不同类型的机会就越小，它们可以显示相同的行为。
io.Reader 和 io.Writer 就是有用接口的一个很好的例子，它们有数以百计的实现。或者是最经典的 error 接口，它非常强大，可以在 Go 中实现整个错误处理。
记住，你可以从其他接口组合一个接口。这里有一个例子：ReadWriteCloser 由 3 个较小的接口组成。
代码如下：
type ReadWriteCloser interface { io.Reader io.Writer io.Closer}在传统语言中，诸如 User、Request 等名词性接口非常常见。而在 Go 语言中，大多数接口都有后缀：Reader、Writer、Closer 等。这是因为，在 Go 中，接口暴露了行为，而它们的名称则指向该行为。
在 Go 中定义接口时，你定义的不是 "某物是什么"，而是 "它提供了什么"-- 是 "行为"，而不是 "事物"！
这就是为什么 Go 中没有 File 接口，但有Reader 和 Writer：这些都是行为，而 File 是实现 Reader 和 Writer 的事物。
《Effective Go》也提到了同样的观点：
Go 中的接口提供了一种指定对象行为的方法：如果某个东西可以做到这一点，那么它就可以用在这里。
在编写接口时，尽量考虑动作或行为。如果你定义了一个名为 "Thing" 的接口，问问自己为什么这个 "Thing" 不是一个结构体。
我经常在代码审查中看到这种情况：很多开发者在同一个包，既写了具体的实现，又定义了接口。
生产者定义的接口
但是，也许客户端并不想使用生产者接口中的所有方法。请记住 "接口隔离原则" 中的一句话："不应强迫客户端实现其不使用的方法"。
下面是一个例子：
package main// ====== producer side// This interface is not neededtype UsersRepository interface { GetAllUsers() GetUser(id string)}type UserRepository struct {}func (UserRepository) GetAllUsers() {}func (UserRepository) GetUser(id string) {}// ====== client side// Client only needs GetUser and// can create this interface implicitly implemented// by concrete UserRepository on his sidetype UserGetter interface { GetUser(id string)}如果客户端想使用生产者的所有方法，可以使用具体的结构体。因为结构体方法已经提供了这些行为。
即使客户端想要解耦代码并使用多种实现，他也可以在自己这边创建一个包含所有方法的接口：
在客户端定义的接口
由于 Go 中的接口是隐式满足的，所以这些事情才得以实现。客户端代码不再需要导入某个接口并编写实现，因为 Go 中没有这样的关键字。
如果实现与接口有相同的方法，那么实现就已经满足了该接口，可以在客户端代码中使用。
如果一个方法返回的是接口而不是具体的结构，那么调用该方法的所有客户端都将被迫使用相同的抽象。
你需要让客户端决定他们需要什么样的抽象，因为代码是他们的庭院。
当你想使用结构体中的某项功能时，却因为接口没有公开它而无法使用，这是很烦人的。这种限制可能是有原因的，但并非总是如此。
下面是一个人为的例子：
type Shape interface { Area() float64 Perimeter() float64}type Circle struct { Radius float64}func (c Circle) Area() float64 { return math.Pi * c.Radius * c.Radius}func (c Circle) Perimeter() float64 { return 2 * math.Pi * c.Radius}// NewCircle returns an interface instead of structfunc NewCircle(radius float64) Shape { return Circle{Radius: radius}}func main() { circle := NewCircle(5) // we lose access to circle.Radius}在上面的示例中，我们不仅无法访问 circle.Radius，而且每次要访问它时都需要在代码中添加类型断言：
shape := NewCircle(5)if circle, ok := shape.(Circle); ok { fmt.Println(circle.Radius)}因此在设计上，请遵循 Postel 定律：“发送时要保守，接受时要宽松”，从方法中返回具体的结构，并选择接受接口。
结合现实的代码，例如原本的代码是：
// Save writes the contents of doc to the file f.func Save(f *os.File, doc *Document) error但入参是 f *os.File，这并不灵活，也不便于测试。我们可以通过上面提到的接口方式，改造为如下代码：
// Save writes the contents of doc to the supplied// Writer.func Save(w io.Writer, doc *Document) error假设一个场景，你有一个导出名为 User 的类型的软件包，你实现了 Stringer 接口。
因为出于某种业务原因，当你打印时，你不希望显示 email 字段。需要如此实现逻辑：
package userstype User struct { Name string Email string}func (u User) String() string { return u.Name}客户端的代码如下：
package mainimport ( "fmt" "pkg/users")func main() { u := users.User{ Name: "脑子进煎鱼了", Email: "xxx@gmail.com", } fmt.Printf("%s", u)}这将正确输出：脑子进煎鱼了。
现在，假设你进行了重构，不小心删除或注释了 String() 的实现，你的代码看起来就像这样：
package userstype User struct { Name string Email string}在这种情况下，您的代码仍然可以编译和运行，但输出结果将是 {脑子进煎鱼了 xxx@gmail.com}。没有任何程序反馈来提示你出现了问题。编译器也不会报错。
这种场景下，为了强制校验某个类型是否实现了某个接口，我们可以这样做：
package usersimport "fmt"type User struct { Name string Email string}var _ fmt.Stringer = User{} // User implements the fmt.Stringerfunc (u User) String() string { return u.Name}我们再尝试一次。现在如果我们删除 String() 方法，就会在构建时得到如下结果：
cannot use User{} (value of type User) as fmt.Stringer value in variable declaration: User does not implement fmt.Stringer (missing method String)在该行中，我们试图将一个空的 User{} 赋值给一个 fmt.Stringer类型的变量。由于 User{} 不再实现 fmt.Stringer，我们得到了程序的报错反馈。
我们在变量名中使用了 _，因为我们并没有真正使用它，所以不会执行真正的分配。
上面我们看到 User 实现了接口。User 和 *User 是不同的类型。因此，如果你想让 *User 实现它，你可以这样实现：
var _ fmt.Stringer = (*User)(nil) // *User implements the fmt.Stringer并且通过这种实现，IDE 会显式提示我们的方法是否有缺失。少了的话会有报错提示：
图片
还是非常方便的。当然，这个小技巧，不需要对每个实现接口的类型都这样做，根据需求对于有必要强校验的接口即可。
今天这篇文章给大家介绍了六种常见的接口设计错误：创建了太多的接口、方法太多了、没有编写行为驱动的接口、在生产者端编写接口、正在返回接口、没有验证接口合规性。
我还记得以前看到某个项目里，写了个接口，20～30 个有待实现的方法。然而他就真的只是一个接口，那么多年过去了也没有人再去实现这个接口。
当然，本文提供的很多接口优化建议，也是需要结合你的实际代码（业务）场景去考虑的。大家各取所需，学习之即可。
本文链接：http://www.28at.com/showinfo-26-98556-0.html六个常见的 Go 接口设计错误
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 秒杀系统架构解析：应对高并发的艺术
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
