go语言interface设计的一点思考

Posted 2023-02-23 -_-void

昨天到公司看到有人在群里把go跟java的interface做比较，提出go宣称的“非侵入式”好像也没那么好用，甚至跟java差不多。但实际上go语言的接口设计并不只是语法本身，也包含了开发流程跟思维方式在里面，下面把当时在群里的回答整理一下放出来。

其实可以这样来理解：
Java语言的开发风格是设计先行，即先定义规范，然后去挨个实现（就是先定义有什么方法，然后再写出来方法体）。
而go语言是“先做再说”，即先把功能实现，然后抽取出接口。
在实际开发流程中，早先的从文档到代码的流程，确实Java更符合。但是开发流程本身也是在发展的，比如后来居上的敏捷流程就让Java出现了雪崩的感觉（给interface加个东西，所有声明implement该interface的都会报错）。但是go就比较贴合这种流程，首先出现的是具体干活的实体，实体多了才抽象出的接口，有了接口之后新写的代码可以使用interface作为参数类型，同时不会导致原有代码编译失败。这就允许开发者随意在未来的任何时间来重构代码，或者不做任何修改，这才是“非侵入式”。

群里当时那问题，举例说定义了“插座”这个接口，定义“微波炉”和“空调”去实现这个接口，后来“插座”多了个“开关”方法，就导致“微波炉”和“空调”也需要实现“开关”这个方法。我当时觉得他说的插座应该是想说能插电的设备，于是在回答的时候用的是“电器”，对这个问题我是这么回答的：

然后说下你的问题，在java中可能是先在设计阶段，就定好了插座、微波炉、空调及他们之间的关系。后面设计变更加上了“开关”这个方法。但是go语言的风格是用什么就做什么，需要有东西加热食品，就先做微波炉，需要有东西调节气温，就做出个空调。然后发现公共部分可以抽象出来一个“电器”接口，于是就有了这个interface。这一过程的任何阶段，在go语言风格中都是编译通过的，至于是否需要把原来以空调或微波炉为参数的func重构为以电器，就可以根据实际情况来了。然后“开关”这个方法也不是凭空出现在接口中的，而是在实际开发中，发现微波炉需要有“开关”功能，然后给微波炉实现了；然后发现空调也用到了“开关”功能也加上了，这个时候开始思考是不是“电器”都需要“开关”呢，于是电器这个接口就有了“开关”。

实际上人不可能一开始就把东西设计的很完美，所以先定义后实现的路子走下来就是，设计变更带来的改动很大。而go这种先实现好实体，然后抽象出接口的思想，就更贴合实际。所以说go语言的interface设计不只是语法，更是一种思维方式。实际上Rob Pike在GoogleIO上讲go语言对并发支持的由来，就是“real world”本身就是很多事情在各自独立互不影响的进行着。

略表拙见，如果有大佬路过发现哪里不妥的感谢指正！