注意细节
抢占抽象让系统变得复杂
原文链接：https://www.f2er.com/go/187359.html
在之前的文章中，我提到了一个关于
accept interfaces,return structs的参考指南，在查看同事代码的时候经常会被问“为什么”。特别是这不是一个必须遵守的规则。这个想法的关键点以及理解什么时候妥协，在于维护项目灵活性和避免抢占抽象（译者注：“Preemptive abstractions” 并发系统中连续组件的轻量级验证方案的一种抽象技术）之间的平衡。
除了因为太多的迂回方式所造成的问题之外，所有的计算机科学问题都能够通过另一个级别的迂回方式来解决。
- David J. Wheeler
软件工程师喜欢抽象。个人看法，我从未看到过一个同事参与写代码超过他为了某个事务建立抽象多。Go 语言从结构中抽象出接口，这种处理方式会产生嵌入复杂性。遵循
你并不需要它软件设计理念，如果不需要就没有理由增加复杂性。一个常见的返回接口的理由是让用户把注意力放在函数所提供的 API 上。在 Go 中因为隐含实现了接口，所以这并不需要。返回结构的公共函数就成为那个API。
永远只有当你真正需要的时候才抽象，不要因为预见可能会需要而抽象
一些语言需要你预见每一个可能从未用过的接口。隐含实现接口一个最大的好处，就是允许你在后面实际需要的时候优雅的抽象事务，而不是需要你预先抽象出来。
使用者眼中的需求
当你真正需要他们的时候
你怎么知道什么时候需要抽象？对于返回类型来说，比较容易。你是写函数的人，所以你确切的知道什么时候需要抽象返回值。
对于输入参数来说，是否需要不在你的控制范围之内。你也许认为你的数据模型足够了，但是一个用户可能需要和某些属性封装一下。如果可能的话，可以预想一下每个调用你的函数的情况，但这是比较困难的。这种可以控制输出，但是不能预期用户输入的不平衡的状况产生了一种强烈的偏见，抽象输入而不是输出。
去掉无用的代码细节
复杂的做鸡蛋的方法
func
addNumbers(a
int,b
string)
int{
returna + b}
对于大多数程序员来说很明显参数
s是不需要的。当参数是结构的时候就不那么明显了。
typeDatabase
struct{ }
func(d *Database)
AddUser(s
string) {...}
RemoveUser(s
NewUser(d *Database,firstName
string,lastName
string) { d.
AddUser(firstName + lastName)}
就像一个写满了配料的菜单一样，NewUser 输入参数是一个有很多功能的 Database 对象。实际上只需要 AddUser 但是却得到了额外的 RemoveUser。接口允许我们在创建函数的时候只依赖我们需要的功能。
typeDatabaseWriter
interface{
AddUser(
string)}
NewUser(d DatabaseWriter,116);">AddUser(firstName + lastName)}
总结理由和审查例外情况
主要的理由如下：
这些理由也允许有例外的情况。例如，如果你的函数实际上返回多种类型而不是一个接口。同样地，如果函数是私有的，你能控制输入参数，会偏向于不要做抢占抽象。对于第三条规则，go 没有方式可以抽象出结构成员的值。 所以，如果你的函数需要访问结构成员（并且不只是结构方法），那么你必须接受结构作为参数。
问答
提问：如果 Database 有很多方法，比如 20 个，那么如何处理呢？
作者：Jack Lindamood译者：tyler2018校对：polaris1119
[backcolor=rgba(24,241,24,0.1)]
本文由 GCTT 原创翻译，
Go语言中文网首发。也想加入译者行列，为开源做一些自己的贡献么？欢迎加入
GCTT！
翻译工作和译文发表仅用于学习和交流目的，翻译工作遵照 CC-BY-NC-SA 协议规定，如果我们的工作有侵犯到您的权益，请及时联系我们。
欢迎遵照 CC-BY-NC-SA 协议规定转载，敬请在正文中标注并保留原文/译文链接和作者/译者等信息。
翻译工作和译文发表仅用于学习和交流目的，翻译工作遵照 CC-BY-NC-SA 协议规定，如果我们的工作有侵犯到您的权益，请及时联系我们。
欢迎遵照 CC-BY-NC-SA 协议规定转载，敬请在正文中标注并保留原文/译文链接和作者/译者等信息。
文章仅代表作者的知识和看法，如有不同观点，请楼下排队吐槽
