This was great for me:
http://golangtutorials.blogspot.com/2011/05/table-of-contents.html
Interfaces part:
http://golangtutorials.blogspot.com/2011/06/interfaces-in-go.html
-- rodrigo
It's a hoary example to use geometry as an example of abstract computations, but there's an important detail here. It's always bothered me in OO languages that we can make Circle, Square, etc. subclasses of Shape (say), but that's the one design decision we get to make. What if we want to align those things along other axes (so to speak), like topological genus or plant genus, if you're a landscaper? You might lose your way or dig yourself into a hole with multiple inheritance.
In Go, that's a non-issue: Circle can satisfy independent interfaces for TopologicalGenus or GrassGenus as well as Area or Perimeter or Symmetry or whatever. Moreover, you don't have to work them all out ahead of time; the whole design can evolve without invalidating early decisions.
This point is critical to interfaces in Go, but people coming from an OO background don't seem to get it. By stopping at one interface for shapes, the author misses a chance to say something vital.
Go's interfaces aren't a variant on Java or C# interfaces, they're much more. They are a key to large-scale programming and adaptable, evolutionary design.
-rob
In Go, that's a non-issue: Circle can satisfy independent interfaces for TopologicalGenus or GrassGenus as well as Area or Perimeter or Symmetry or whatever. Moreover, you don't have to work them all out ahead of time; the whole design can evolve without invalidating early decisions.
@rodrigo I discovered these and in fact interfaces are much clearer now.
After following some discussion on this list I have the same sentiments as @robpike though, that Shapes are the canonical example coming from an OO language but an otherwise oversimplificating decision to explain the concepts.
He is right; I pretty much understand and agree.
It was a good introduction for me because it had the keywords I was
looking for. It helped me to get started, even though later I realized
that we don't translate concepts like that. Maybe Go needs a
definitive introduction for people coming from OO; I'm a slow learner
and that one filled a void for me.
-- rodrigo
In Go, that's a non-issue: Circle can satisfy independent interfaces for TopologicalGenus or GrassGenus as well as Area or Perimeter or Symmetry or whatever. Moreover, you don't have to work them all out ahead of time; the whole design can evolve without invalidating early decisions.
-rob
Now imagine that class C has a method that isn't in those interfaces
(e.g. Color), and you want to write some code that uses, say, the Area
and Color methods (e.g. to calculate the quantity of paint you need to
buy). In languages like C++, Java or C# you have to go edit the
definition of class C to say that it implements your new interface; in
Go, you simply define the interface and there's no need to change
class C.
That matters a huge amount in big programs, because you can happily
keep adding more and more interfaces without worrying that it's going
to make your class C look messy. It also means that you aren't at the
mercy of whoever owns class C. It also means you don't have to
recompile class C.
In Go, interfaces are *truly* independent. They aren't just a type
that you declare and then have to go modify all your code to say which
things implement that interface.
Dave.
There are lots of limitations with this.
1. You have to convince whoever is in charge of "class C" to add this
interface to the implements list.
2. Having the implements list include more than a dozen interface names
gets problematic.
3. A subset of the methods of a class might have a completely different
meaning to you than someone else.
type CookieJar interface {
Get(key string)(value string,err error)
Put(key string,value string)(err error)
}
type AddressBook interface {
Get(key string)(value string,err error)
Put(key string,value string)(err error)
}
etc.
Both are satisfied by the KeyValueStore type, but it would be really
weird for KeyValueStore to say it implemented CookieJar and AddressBook.
For a reasonably sized class the number of possible interfaces it could
satisfy can be quite large.
- jessta
Go's interfaces aren't a variant on Java or C# interfaces, they're much more. They are a key to large-scale programming and adaptable, evolutionary design.
To my understanding: Almost none. The only difference is that just
typing "implements MyNewInterface" is _not_ enough in Java: You have
to recompile the whole stuff (iff you have the sources...).
interface Storable extends Comparable, Serializable{ }
void storeInOrder(Storable item){ … }
class Kitten implements Comparable, Serializable{ … }
class StorableKitten implements Storable{
Kitten k;
StorableKitten(Kitten k){ this.k = k; }
int compareTo(Object o){ return k.compareTo(o); }
…
}
Kitten k = …;
storeInOrder(new StorableKitten(k));
type Storable interface {
Comparable
Serializable
}
The way you mapped traditional OO to Go was really helpful to me and I think your Go articles are one of the best introductions out there.
I look forward to your take on this thread.
Adam