一：接口的一些想法
最近在研究go语言，看到接口这一章时，萌生一些想法，苦于周围没有golang的大牛，只能提笔撰文于此，与大家一同探讨
首先说明下 本人是一枚java程序员，接触java也有一段时间了，java掌握的还可以，闲来无聊便研究起了golang 好了不说那么多废话了 直接干货
golang的接口让我最惊讶的地方在于方法的实现方式，按照官方的说法，只要实现了接口中的方法，该结构体自然就实现了该接口，在我看来这无疑是一个冒险的尝试，尽管这样的说很大程度上解放了程序员的双手，代码变得更加简洁 ，但是也带来一些弊端，例如当一个中大型项目中接口急剧膨胀式时（oo的特性决定了接口的设计成了家常便饭），难免会产生一些重名的方法 假如A接口中的 x,y方法同样存在B接口中 那么当某一个结构实现x,y方法时 也就同时实现了A，B这两个接口 而编写这个结构体的coder初衷肯定只是希望实现其中一个，显然这样一来 这个结构体在使用时必然存在着一定的风险 由于没有显式的指出到底实现的是哪一个，调用时存在着灰常高的风险，而且伴随这代码量的增多 这种情况机会不可避免多人协作开发的项目，接口的编写 不可能完全交由架构师来完成吧。
有时候我们可能只是简单的想要给结构体绑定一些方法，并未曾想让他实现某些接口，但是很有可能在我门绑定方法的时候无意间实现了某个接口，原因很简单 我们绑定的方法名与接口的方法名重名了。这种状况几乎很难排查。这姑且称作是无意间干了一些不该干的事儿

同java码畜,其实java里也会存在这个问题，但是却怎么避免的呢？package, go 里也可以这样来避免吧～

类实现多个接口，在go里面十分常见，比如bytes.Buffer,既是Reader,又是Writer,同时还是别的。使用时真的要理解这个类才行。