<story><title>Golang concepts from an OOP point of view</title><url>https://github.com/luciotato/golang-notes/blob/master/OOP.md</url></story><parent_chain></parent_chain><comment><author>gabesullice</author><text>While I appreciate that this is a work in progress and meant for learning, i just want to caution readers and those new to Go that this is a somewhat dangerous way to approach Go.&lt;p&gt;Simply mapping familiar vocabulary from an traditional OO language into Go implies that the differences are superficial and the underlying concepts are largely the same. The truth is that a lot of the traditional vocabulary was very intentionally left out of Go.&lt;p&gt;For example, mapping  embedded stucts to &amp;quot;multiple inheritance&amp;quot; masks the fact that Go is trying to guide you into understanding the power of composition over inheritance. It&amp;#x27;s not that it&amp;#x27;s impossible to understand that, but by carrying over the terminology, you burden yourself with some preconceptions.&lt;p&gt;Like I said, I know this is a work in progress, but I encourage you to perhaps map the terms but then write a paragraph or two about how they&amp;#x27;re _different_, not the same.&lt;p&gt;This was a really nice resource for me when I first came to Go: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;spf13.com&amp;#x2F;post&amp;#x2F;is-go-object-oriented&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;spf13.com&amp;#x2F;post&amp;#x2F;is-go-object-oriented&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>Golang concepts from an OOP point of view</title><url>https://github.com/luciotato/golang-notes/blob/master/OOP.md</url></story><parent_chain></parent_chain><comment><author>chimeracoder</author><text>&amp;gt; This is a discovery process, I&amp;#x27;m writing this document to help myself understanding golang and maybe help others.&lt;p&gt;First: I took a brief look through this, and I didn&amp;#x27;t see anything that jumped out as wrong. It&amp;#x27;s a pretty comprehensive document, especially for someone who says they&amp;#x27;re just starting out, so kudos to James for writing it!&lt;p&gt;That said, from my experience in teaching Go classes and workshops for beginners, comparing embedding to inheritance is usually a bad idea. It&amp;#x27;s not that there aren&amp;#x27;t similarities, but in my experience it prompts new Go programmers to write unidiomatic Go code when they think of embedding in that way. They end up embedded structs the way they&amp;#x27;d use inheritance in object-oriented languages, and since Go isn&amp;#x27;t really intended as an object-oriented language, it makes for unidiomatic code.&lt;p&gt;The main use cases of inheritance in OOP are accomplished by interfaces in Go, not struct embedding. But at the same time, the main benefits of embedding come from embedding &lt;i&gt;interfaces&lt;/i&gt; - embedding structs is almost an afterthought in the language. In fact, I tend to advise people against embedding structs altogether. There are a few cases where it&amp;#x27;s worthwhile to embed structs, but the use case for embedding interfaces is much more powerful.&lt;p&gt;My advice for Go beginners: use interfaces more than you think you need to, and forget that struct embedding is even possible. This rule of thumb helps to write more idiomatic Go code when you&amp;#x27;re just getting started, before you have a feel for what that really means.</text></comment>