注意细节
在之前的文章中，我提到了一个关于 accept interfaces, return struct s 的参考指南，在查看同事代码的时候经常会被问“为什么”。特别是这不是一个必须遵守的规则。这个想法的关键点以及理解什么时候妥协，在于维护项目灵活性和避免抢占抽象（译者注：“Preemptive abstractions” 并发系统中连续组件的轻量级验证方案的一种抽象技术）之间的平衡。
抢占抽象让系统变得复杂
- David J. Wheeler
软件工程师喜欢抽象。个人看法，我从未看到过一个同事参与写代码超过他为了某个事务建立抽象多。Go 语言从结构中抽象出接口，这种处理方式会产生嵌入复杂性。遵循 你并不需要它 软件设计理念，如果不需要就没有理由增加复杂性。一个常见的返回接口的理由是让用户把注意力放在函数所提供的 API 上。在 Go 中因为隐含实现了接口，所以这并不需要。返回结构的公共函数就成为那个API。
永远只有当你真正需要的时候才抽象，不要因为预见可能会需要而抽象
一些语言需要你预见每一个可能从未用过的接口。隐含实现接口一个最大的好处，就是允许你在后面实际需要的时候优雅的抽象事务，而不是需要你预先抽象出来。
使用者眼中的需求
当你真正需要他们的时候
你怎么知道什么时候需要抽象？对于返回类型来说，比较容易。你是写函数的人，所以你确切的知道什么时候需要抽象返回值。
对于输入参数来说，是否需要不在你的控制范围之内。你也许认为你的数据模型足够了，但是一个用户可能需要和某些属性封装一下。如果可能的话，可以预想一下每个调用你的函数的情况，但这是比较困难的。这种可以控制输出，但是不能预期用户输入的不平衡的状况产生了一种强烈的偏见，抽象输入而不是输出。
去掉无用的代码细节
复杂的做鸡蛋的方法
简化的另一个方面是去除不需要的细节。类似菜单函数：给一个输入然后你得到一个蛋糕！不需要列出做蛋糕的材料。同样的，函数也不需要列出不使用的输入参数。下面的函数你会怎么想？
func addNumbers(a int, b int, s string) int {
return a + b
}
对于大多数程序员来说很明显参数 s 是不需要的。当参数是结构的时候就不那么明显了。
type Database struct{ }
func (d *Database) AddUser(s string) {...}
func (d *Database) RemoveUser(s string) {...}
func NewUser(d *Database, firstName string, lastName string) {
d.AddUser(firstName + lastName)
}
就像一个写满了配料的菜单一样，NewUser 输入参数是一个有很多功能的 Database 对象。实际上只需要 AddUser 但是却得到了额外的 RemoveUser。接口允许我们在创建函数的时候只依赖我们需要的功能。
type DatabaseWriter interface {
AddUser(string)
}
func NewUser(d DatabaseWriter, firstName string, lastName string) {
d.AddUser(firstName + lastName)
}
Dave Cheney 在写 接口隔离原则 的时候也提到了 这一点 。他还描述了一些关于限制输入的其他好处，值得读一下。概括一下就是：
依照需求描述的结果也就是函数-仅仅是需要可写并且提供相应的功能
我会按照这个思想，重新考虑上面的函数 addNumbers，很明显不需要参数 s 字符串，函数 NewUser 同样也不需要一个包括 RemoveUser 的Database参数。
总结理由和审查例外情况
主要的理由如下：
- 移除不需要的抽象
- 在函数参数上用户需求的歧义
- 简化函数参数
这些理由也允许有例外的情况。例如，如果你的函数实际上返回多种类型而不是一个接口。同样地，如果函数是私有的，你能控制输入参数，会偏向于不要做抢占抽象。对于第三条规则，go 没有方式可以抽象出结构成员的值。 所以，如果你的函数需要访问结构成员（并且不只是结构方法），那么你必须接受结构作为参数。
问答
提问：如果 Database 有很多方法，比如 20 个，那么如何处理呢？
回答：一个结构可能有 20 个方法，但是一个方法不需要调用那么多方法。 试着把这些方法按组分类，比如读的方法，写的方法，管理的方法等等。这样需要 Database 的函数可以使用方法子集来处理。
via:
作者：Jack Lindamood 译者：tyler2018 校对：polaris1119
本文由 GCTT 原创编译，Go语言中文网 荣誉推出
