I keep wondering if Go couldn't have gone further in getting rid of the cruft that has accumulated around OO. Go doesn't have an implicit "this" pointer. It doesn't have members that are private to an individual object nor members private to a type. Encapsulation exists only at the package level.<p>Yet Go keeps that old OO concept of method receivers. Why? I never found it very plausible to have one special case parameter with its very own syntax, but with type level encapsulation it did at least have some justification.<p>Without this kind of encapsulation, the only remaining purpose of the receiver is method dispatch. But why dispatch based on the type of one parameter and not the others? Multimethods would have been the logical conclusion of the OO cleanup that Go's designers apparently intended to achieve.
Here is the article that got me onto the way of go: <a href="http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/" rel="nofollow">http://areyoufuckingcoding.me/2012/07/25/object-desoriented-...</a>
The memes are a bit much but the content is solid.
For an understanding how to do OO design in Go, learning about component programming is a good way.<p><a href="http://www.amazon.de/Component-Software-Beyond-Object-Oriented-Programming/dp/0201745720" rel="nofollow">http://www.amazon.de/Component-Software-Beyond-Object-Orient...</a><p>The first edition used Component Pascal from the Oberon family, which Go gets some influence from. Later editions used Java and C# instead.<p>Additional learning about how COM and XPCOM work is also a way to get some ideas.
> To apply the uniform access principle to the Part type, we could change the struct definition and provide setter/getter methods<p>If you have to <i>apply</i> it, it isn't <i>uniform</i> access. The point of the principle is that the call-site shouldn't distinguish between getters and fields so that the implementer can change that decision freely without breaking callers.<p>Nice article, though!
I have a question about go. Let's say I have a struct Foo and a function/method for Less. What is the quickest way to sort an array of Foo's?<p>Do I have to implement my own []Foo type with all three methods as described in the sort package?
Is there any advantage to using OO in a language that doesn't have classes or inheritance? Does declaring a method on a type give you something that declaring a function that takes the type as an argument doesn't?
One of the most common problems people have when they get to know Go is to not embrace its approach to programming, but try to enforce what they already know in Go programs.<p>This is a clear example of that. Implementing “polymorphism” with Go interfaces is abusing interfaces! Seeing embedding as inheritance misses the point of both embedding and inheritance. Comparing packages to namespaces isn’t that bad, but just delays you getting to know Go for real.<p>I’m not saying that these old concepts are bad or Go’s new approach is superior. (I believe in that; but that’s not the point here.) I’m saying if you’ve gotten used to these concepts so much that you can’t think or program without them, then there’s a problem. Don’t design a solution around polymorphism or inheritance and then try hard to force that into Go. Design your program with that your language is giving you.
Off-topic, but it would be nice if the blog didn't use <i>24-pixel body type</i>, so that I could see more than a handful of lines at a time on my laptop.<p>I've never seen a book with 24-point body type, except possibly for the visually impaired or 3-year-olds. Heck, most <i>headings</i> aren't even 24 point. What is it with this blog trend of gargantuan type, which seems increasingly common? It's totally out of proportion with the rest of anyone's OS and computer interface, and all the common sites. I'm really getting tired of having to zoom <i>out</i> to an insane <i>50%</i> level just to make things legible again.
Good article - this covers the basic OO patterns in Go. I really like the simplicity of the design - objects are just structs and you can define a method for that object. Coming from C#, it's like every method is an extension method.<p>The only critique I have is that there's no way to verify that object X implements methods A, B, and C. When I'm using C# or Java, I often use an interface as a test to make sure I've done my work since the code won't compile if a class that extends an interface fails to implement all the methods.