<p>I'm just learning GO and i cant help feeling that it's over simplify things sometimes. For instance implicit interface implementation removes the obligation from the implementor of a interface to understand what the are implementing, just assuming that types that have the some method signiture that are the same can be used polymorphicaly is a bit dangerious.
For instance:
cake.Eat(me)
lion.Eat(me)
calling these methods may result in very different experiences.</p>
<hr/>**评论：**<br/><br/>dsymonds: <pre><p>In theory, yes, it could cause problems.</p>
<p>In practice, it pretty much never does.</p></pre>bkeroack: <pre><p>That's a weird example. The cake isn't eating you.</p></pre>quiI: <pre><p>In what way does </p>
<pre><code>MyClass implements Eater
</code></pre>
<p>Giving you any more information? With most traditional statically typed languages all you're getting as an implementer of an interface are clues in the form of types. </p>
<p>You still get this with Go, just without the boilerplate and you get a lot more flexibility</p></pre>cs-guy: <pre><p>I had the same worry when I first started learning Go. As I became comfortable with the language the worry went away and the benefits of implicit interface implementation became more clear. Now I believe it is one of the best aspects of the language. It allows for better decoupling of types and packages, which is a very good thing.</p></pre>GopherFromHell: <pre><p>having implicit interfaces also has the effect of making interfaces smaller and more useful by consequence.</p></pre>kavehmz: <pre><p>Just adding to reasons,</p>
<p>In explicit implementations sometime you spend a lot of time in beginning of project to design your interfaces. At that time you might not know the best design you need. So you will end up doing more refactoring.</p>
<p>In Go's implicit way, you can define your interfaces later in the project or add interfaces to old code without extensive refactoring.</p></pre>
