Will a new programmer learning Go have a deficiency in their Object Oriented Programming knowledge?

<p>I am staring to learn Programming again (I learned C at some point), and have started learning Go. I am learning for my own knowledge and a data analysis project I am working on. My concern is by learning Golang and its unique take on OOP, will there be a fundamental flaw in the way I approach problems? If need how hard is the transition from Golang to Full OOP?</p> <hr/>**评论：**<br/><br/>qu33ksilver: <pre><p>It&#39;s true that Go does not approach problems in your traditional C++ way. So, you won&#39;t be learning the traditional classes and inheritance. But the important question is why do you consider not knowing OOP to be a &#34;bad&#34; thing. </p> <p>OOP is just one way of approaching problems which several programming languages leverage. But there are tradeoffs. Other languages don&#39;t use OOP completely.</p> <p>Consider a different question - </p> <p>&#34;Will a new programmer learning C++ have a deficiency in their Functional Programming knowledge ?&#34;</p></pre>apv0: <pre><p>Thank you, I was under the impression OOP was the be all and end all of big boy programming. </p></pre>sin2pifx: <pre><p>While all this talk may have theoretical merit, in practice, OOP means inheritance. If you interview somewhere and you say you know OOP, they&#39;re going to assume you&#39;re familiar with the Java/C++ model, which knowledge of just Go would cover only partially.</p></pre>jimbishopp: <pre><p>Seems like the fundamental flaw is the thought that OOP is the appropriate way to approach problems. </p> <p>I&#39;ve experienced good results by organizing around WHAT the program will do instead of the THINGS that are required to do it.</p> <p>OOP was originally focused on the WHAT (messaging) but seems to have morphed into a focus on THINGS (for a while now...); Alan Kay: <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html" rel="nofollow">http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html</a></p> <p>Edit: and Go is an excellent way to learn this... :)</p></pre>apv0: <pre><p>Thank you, It seems a lot of GO fans are Smalltalk fans and vice versa. I was not familiar with Smalltalk until my research into GO. The link to Mr. Kay&#39;s message was informative.</p></pre>patrickdlogan: <pre><p>There is a sufficient amount of commonality that moving between Go and an(other) Object Oriented language should not be difficult.</p> <p>A core principle of OOP is to distinguish protocol contracts from implementation details that do not alter the contract.</p> <p>In Go protocol contracts are defined by interfaces. Implementation details are the values that have methods satisfying an interface.</p></pre>apv0: <pre><p>Thank you for your response, the terms protocol contracts vs implementation details helped in understanding the concept. </p></pre>jhlahsklfahdfkl: <pre><p>Go gives you all the mechanisms necessary to write in a fully OOP style.</p> <p>Receivers which conceptually transform functions into methods to satisfy messaging requirements. Composition of types and the use of unexported fields and methods to satisfy the requirements for encapsulation. Messaging and encapsulation is the essence of OOP, nothing else is needed to satisfy the requirements for OOP, everything else is something else - some other paradigm.</p></pre>egonelbre: <pre><p>I think the question is somewhat flawed. Paradigm isn&#39;t a property of a language of a language, but rather the way you think about the problem. In a sense you can write OOP-ish code in assembly... (<a href="https://medium.com/@egonelbre/paradigm-is-not-the-implementation-af4c1489c073" rel="nofollow">https://medium.com/@egonelbre/paradigm-is-not-the-implementation-af4c1489c073</a>)</p> <p>As for expressing OO ideas in Go... the main thing you might hit is inheritance. There&#39;s no equivalent for Go... but from experience, designs without inheritance are easier to understand and follow (at the cost of conciseness in some places)</p></pre>omac777: <pre><p>Golang won&#39;t twist your previous conceptions of OOP. You know C so I will do my best to bootstrap you into golang from that: 1)structures in golang and structures in c are essentially the same 2)how you declare your structure, how you define your structure and how you use it are a touch different. 2.1) In C you could to forward declare your structure in advance without defining its contents. I have never done that in golang, but I believe you can. 2.2)In C, when you define the structure, you are simply defining it and you don&#39;t usually instantiate it at the same time. It&#39;s the same in golang in this respect. Where they differ is that usually in golang you are declaring and defining it at the same time without instantiating it in a variable. You&#39;ll do that when you do your implementation usage. 2.3)In golang, you may instantiate a structure and initialize it in one line effectively. In C, it takes more than one line. 3)C struct, golang struct and c++ class are very similar. The only difference is C struct/golang struct members are public in scope from the beginning while c++ class members might not be for whatever reason. C struct/golang struct may also contain pointers to functions which may possibly have the same behaviour as what C++ provides, but GOLANG differs greatly from C and C++ here when discussing the recommended way to associate functions with golang structs. ok NOW let&#39;s talk about the golang &#34;type&#34; keyword. In my humble opinion, the golang &#34;type&#34; is what you call a C struct and what I have mentioned golang struct previously. &#34;type&#34; is more powerful when using the golang-recommended of associating functions to specific user-defined &#34;type&#34;s. With those functions, it almost feels like OOP and certainly resembles python&#39;s and perl&#39;s way of implementing OOP. For me it feels easier to use. The other advantage are the tight compile/link cycles. THE GO COMPILER IS SO DARN FAST!!!! Have a look at the answer here about what books best summarize golang usage and how to stay up to date with it: <a href="https://www.reddit.com/r/golang/comments/6r1hmz/what_are_the_best_go_books_published_in_2017/" rel="nofollow">https://www.reddit.com/r/golang/comments/6r1hmz/what_are_the_best_go_books_published_in_2017/</a></p></pre>apv0: <pre><p>THANK YOU! For your detailed reply, part of what attracted to me to GO was it&#39;s similarity to C. The brevity of GO syntax is welcome, and something about a complied language just feels better. </p></pre>