<p>I was hoping to get some pointers or references (no pun intended) on thinking and designing applications the 'Go way.'</p>
<p>I come from a strong OO background, mainly Java in an enterprise environment. Sometimes I have trouble when designing Go applications, because in Java everything has a certain organizational pattern that differs greatly from C and Go. </p>
<p>Are there any books or pages online that describe good C/Go/non-OO program design and architecture? Or perhaps some good repos to check out? Or should I blunder on and hope to feel it out?</p>
<p>Thanks in advance!</p>
<hr/>**评论：**<br/><br/>nstratos: <pre><blockquote>
<p>Are there any books or pages online that describe good C/Go/non-OO program design and architecture?</p>
</blockquote>
<p>For resources around this topic, please check out my <a href="https://www.reddit.com/r/golang/comments/56wk4v/structuring_go_api/d8n4axl/">answer</a> to a similar question.</p>
<blockquote>
<p>Or perhaps some good repos to check out?</p>
</blockquote>
<p>Good repos to check out: </p>
<ul>
<li><a href="https://github.com/upspin/upspin">https://github.com/upspin/upspin</a></li>
<li><a href="https://github.com/golang/perf">https://github.com/golang/perf</a></li>
</ul>
<p>Also try to read the standard library and <a href="https://golang.org/doc/effective_go.html">Effective Go</a> as much as possible.</p></pre>__pulse0ne: <pre><p>Thank you very much! I've been through Effective Go and Kernighan's "The Go Programming Language", and while the examples they provide are good for describing some of the syntactical idioms, I felt I needed more direction in the area of the design philosophy. I have a hunch that it's similar to how C programs are designed, but having developed almost exclusively in an OO paradigm, this is a totally new area and way of thinking about things for me. </p></pre>colezlaw: <pre><p>Rather than too many specific references, I'll give some general pointers as somebody who's done development in a whole lot of languages. I've spent most of the past few years primarily in Java and Python, but I do code reviews for many, many languages.</p>
<p>The first reference to look at is the source for the standard library. It's well-written, well-documented, and well-tested. The latter is a good indication that they've designed the standard library in such a way that it's easily testable (one of the first features I look for in good design patterns after being spoiled by a few applications with good testing in Java). You just can't go wrong with the standard library as a starting point for writing idiomatic go.</p>
<p>The other point I'd like to make (and this is true of any programming language, really) is that you should leave your Java (or whatever other programming language) baggage at the door. If you're going to try to write Java code in Go, you'll be disappointed. You'll particularly want to leave some Java anti-patterns at the door, particularly the try-fifty-things-and-catch-Exception pattern. You'll find that good Go code handles each error explicitly, but there are some ideas for being a little less clumsy in <a href="https://blog.golang.org/errors-are-values" rel="nofollow">https://blog.golang.org/errors-are-values</a> .</p>
<p>And the last piece is just bonus material. Some of the best Go libraries that I've seen do a really good job of using goroutines and channels, but don't expose those to the caller. One of the few places (that I've seen so far) where the user of a library needs to handle a channel from the standard library is in the <code>context</code> package. That's not to say it's poorly designed - I love the <code>context</code> package, but it's a rare case where the standard library uses channels and expects the user of the package to deal with a channel from it.</p></pre>65a: <pre><p>net/http uses channels, but doesn't force the user to worry about them. Another example of a place in the stdlib that does expose channels (in a cool way) is time.Ticker.</p></pre>Testiclese: <pre><p>Stop thinking about types. About "nouns". Java is a kingdom of nouns and types. In Java, you start by describing a "thing". </p>
<p>Go starts with functions. Functions are verbs. They do. They <em>act</em> on things. Programs are valuable because they <em>do</em> things not because they <em>describe</em> abstract things. So Go lets you get to the <em>value</em> part quicker. </p>
<p>Start by writing functions that take parameters and return values. Let your types <em>slowly</em> evolve as needed. </p>
<p>Look at how Go does polymorphism. Look at fmt.Fprintf and really <em>look</em> at it. It's a function. Not a method. And it takes a polymorphic type - an interface - as a parameter and <em>uses</em> it. Really think about that and how it differs from the typical Java approach. And then realize how much more light weight and flexible this approach is without losing any functionality. </p>
<p>For me, fmt.Fprintf and http.ResponseWriter.Write were key for grokking Go. </p>
<p>Hope this was helpful. I don't know when exactly Go "clicked" for me - I think it was by just using the std. lib. on toy projects and seeing the patterns come thru. </p>
<p>Stay simple. Be obvious. Don't be cute, don't over-design and over-engineer - those are signs you're doing it wrong. </p></pre>__pulse0ne: <pre><p>Thank you, I really think this was a fantastic way of framing it. The noun/verb metaphor is excellent!</p></pre>kromem: <pre><p>One piece of advice you should stick to religiously for a bit, and then only start breaking once you feel like you understand why it was a piece of advice and when/why you want to break it:</p>
<p>"Accept interfaces and return objects."</p>
<p>I promise you'll start to get how to think in the Go way after a short while of doing this.</p></pre>epiris: <pre><p>Hello, blunder on. If you're an experienced developer your probably fearing what a lot of people do early on. You can be punished pretty harshly in Go for approaching some problems like you would in a OO language. Go prototypes and refractors fast, interfaces let you have zero coupling early while figuring out your problem space and abstract when patterns emerge. </p>
<p>So write code and when something feels cumbersome, lacks eloquence, or simply just won't work paste it into a play and post here or on the gophers slack channel. I always reply to people who ask questions with a example of their problem and I notice a lot others do as well. It doesn't have to run or compile, or even be valid syntax, just illustrate your problem. Even posting a snippet of another language for reference of what you want to do is fine too. Point is don't stress about design early on. Have fun.</p></pre>__pulse0ne: <pre><p>Thank you for your response. I'm having a blast learning and playing with Go.</p>
<p>I've just gotten so used to an enterprise environment and Spring configuration that it almost feels foreign looking at 'main' and figuring out how to start and to organize everything. </p>
<p>I'm absolutely loving channels and goroutines. Syntactically, the language makes sense to me, it's just been organizing and fitting the pieces together in a sane way that has provided somewhat of a challenge. </p>
<p>I'll definitely poke my head into the slack channel if blundering doesn't prove to be fruitful!</p></pre>65a: <pre><p>Use small interfaces instead of inheritance (see io.Writer and io.Reader). In general, write functions that accept interfaces and return structs. Go has some OO-ness, it's just not the Big Inheritance And Large interface model.</p></pre>George3d6: <pre><p>Write code that solves your problems.
If you think it took you too long to write said code try making it shorter and simpler to understand.
If you think your teammates (if any) and you did not collaborate efficiently try deciding on some standards.</p></pre>__pulse0ne: <pre><p>Thanks for the downvote, stranger. I'm glad that going to the community for advice is downvote-worthy. </p></pre>nevyn: <pre><blockquote>
<p>Are there any books or pages online that describe good C/Go/non-OO program design and architecture? Or perhaps some good repos to check out? </p>
</blockquote>
<p>Look to the right, click the thing that says "<a href="http://dave.cheney.net/resources-for-new-go-programmers">Resources for new Go programmers</a>"</p></pre>__pulse0ne: <pre><p>Yes, and I've read many of those. But my question was pretty specific to migrating from an OO-centric paradigm. In the first sentence of the post I asked for pointers from the people in the community. </p>
<p>But your condescension is very much appreciated.</p></pre>nevyn: <pre><p>I haven't downvoted any of your posts, thought you might have missed/ignored the sidebar because for Eg. <a href="http://www.golangbootcamp.com/book/methods" rel="nofollow">http://www.golangbootcamp.com/book/methods</a> talks directly about thought migration from OOP.</p>
<p>It's hard to discern tone online, so it's often better to assume the best (esp. when new or asking for help). I think this subreddit is much more accommodating than other places to ask questions but you have to actually ask specific questions, or share something. Is there some kind of pattern you are used to using that you aren't sure about how to approach that problem now?</p></pre>__pulse0ne: <pre><p>I do apologize, I've been unduly harsh. My bad day is not your fault. </p>
<p>I'm on mobile, so I actually can't immediately see the sidebar. That being said, I have found that, in the resources that are linked to, the examples usually only serve to describe a specific syntactical topic, rather than the language's idiomatic design philosophy. I will absolutely check out the link you have provided, and I do deeply appreciate your help (and for being understanding in spite of me being an asshole)</p></pre>leimy: <pre><p>"Everyone is an asshole here and there. It's the Internet. Welcome!", the man farted.</p></pre>
