btracey (1) [Avatar] Offline
#1
I don't think the chapter 1 comments about the java interface appropriately set the stage for Go interfaces. After showing the definition of the interface, it comments "java requires you to create a class that fulfills all the promises...". This is true in go as well. The go equivalent of the interface would be

type Animal interface{
Eat()
Move()
}

If you want to make a comment about verbosity (Go's lack of public void), then I guess that's okay, but the example code doesn't show anything about how interfaces in java are all encompassing, nor does it show that you explicitly implement the interface. I really don't see the point in having the example code.

It then continues with 'in contrast, go typically has one method'. There are lots of interfaces in go that have two methods. The contrast is not having fewer methods, it's the implicit implementing of them.
brian.ketelsen (14) [Avatar] Offline
#2
Re: Chapter 1: Java interface
Thanks for your input. We'll try to make these examples more useful and clear.
erikstmartin (6) [Avatar] Offline
#3
Re: Chapter 1: Java interface
You're correct. This language should be corrected.

Both Java and Go require you to provide a class/type that fulfills the contract specified in the interface.

The differences lie in the fact that Java requires you to explicitly declare that you implement an interface while Go does not, as well as in idiomatic usage of Go, interfaces are generally thought of as a minimal number of actions (Reader, Writer, Stringer), but not always (heap.Interface), which allows for a broader range of types to fulfill the contract, and often (but not always) in Java applications, an interface is thought of more in terms of an object (Connection).

So the core language difference is just the explicit/implicit implementing of the interface, the usage is not an enforced pattern but is generally the idiomatic way of looking at your problem.
Nathan Youngman (40) [Avatar] Offline
#4
Re: Chapter 1: Java interface
When I read "interfaces are all encompassing. You're often required to think through a large inheritance chain...", my immediate thought was maybe they mean "interfaces" in the API sense rather than the language feature.

After reading further, it sounds like it's actually all about interfaces in Java vs. Go and nothing to do with inheritance. I'm not a Java guy though, so no advice here. Erik's comment cleared it up for me.

The part about getting used to Go if coming from "writing in a very strong object-oriented language like Java" also struck me as a bit odd. In context of types, I suppose Java may be a "stronger" in that it always requires classes. However, the sentences before are talking about interfaces. Does "implements" make it "stronger" OO? Perhaps just nitpicking the word choice here.