注意细节
@H_301_7@
在之前的文章中,我提到了一个关于
accept interfaces,return structs的参考指南,在查看同事代码的时候经常会被问“为什么”。特别是这不是一个必须遵守的规则。这个想法的关键点以及理解什么时候妥协,在于维护项目灵活性和避免抢占抽象(译者注:“Preemptive abstractions” 并发系统中连续组件的轻量级验证方案的一种抽象技术)之间的平衡。
@H_301_7@
@H_301_7@ 除了因为太多的迂回方式所造成的问题之外,所有的计算机科学问题都能够通过另一个级别的迂回方式来解决。
@H_301_7@ 永远只有当你真正需要的时候才抽象,不要因为预见可能会需要而抽象
@H_301_7@ 当你真正需要他们的时候
@H_301_7@ 依照需求描述的结果也就是函数-仅仅是需要可写并且提供相应的功能@H_301_7@ 我会按照这个思想,重新考虑上面的函数 addNumbers,很明显不需要参数 s 字符串,函数 NewUser 同样也不需要一个包括 RemoveUser 的Database参数。 总结理由和审查例外情况 @H_301_7@ 主要的理由如下: @H_301_7@ 这些理由也允许有例外的情况。例如,如果你的函数实际上返回多种类型而不是一个接口。同样地,如果函数是私有的,你能控制输入参数,会偏向于不要做抢占抽象。对于第三条规则,go 没有方式可以抽象出结构成员的值。 所以,如果你的函数需要访问结构成员(并且不只是结构方法),那么你必须接受结构作为参数。 问答 @H_301_7@ 提问:如果 Database 有很多方法,比如 20 个,那么如何处理呢? @H_301_7@ 回答:一个结构可能有 20 个方法,但是一个方法不需要调用那么多方法。 试着把这些方法按组分类,比如读的方法,写的方法,管理的方法等等。这样需要 Database 的函数可以使用方法子集来处理。
文章仅代表作者的知识和看法,如有不同观点,请楼下排队吐槽