Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

I'm curious, I do that in C++ (prefer composition). Does go provide features that help me compose when in Java/C++ I would have to inherit?
–
Doug T.Jul 18 '12 at 15:08

1

@DougT.: Yes, I've edited in an example showing the general idea of (part of) what it allows.
–
Jerry CoffinJul 18 '12 at 15:16

2

I think this misses the point : the difference isn't just a syntactic one implying you use embedding to build your taxonomy. The fact is that the lack of OOP method overriding prevents you to build your classical taxonomy and you must use composition instead.
–
Denys SéguretJul 18 '12 at 15:36

1

@dystroy: Compared to Java, you probably have a point. Compared to C++, not so much -- because (at least among those with a clue) those giant taxonomies were last seen close to 20 years ago.
–
Jerry CoffinJul 18 '12 at 15:53

1

@dystroy: You're still not understanding. A three level hierarchy in modern C++ is next to unheard of. In C++ you'll see those in the iostreams library and the exception hierarchy -- but close to nowhere else. If the iostreams library was being designed today, I think it's safe to say it wouldn't be that way either. Bottom line: your arguments show less about C++ than about how out of touch you are with it. Given that you haven't used it in decades, that makes sense. What doesn't make sense is trying to say how C++ is used based on that dated experience.
–
Jerry CoffinJul 18 '12 at 16:18

That is, you define doComplexThing on the super class as an organization on calls of the specializations.

But in Go, this wouldn't call the specialized function but the "superclass" function.

So, if you want to have an algorithm needing to call some functions defined on *sql.DB but redefined on ConnexionMySQL (or other specializations), you can't define this algorithm as a function of *sql.DB but must define it elsewhere and this function will only compose the calls to the provided specialization.

This is quite different from the classical overriding of class hierarchies.

Especially, you obviously can't directly have a third level inheriting a function implementation from the second one.

In practice, you'll end using mostly (orthogonal) interfaces and let function compose the calls on a provided implementation instead of having the implementation's "superclass" organizing those calls.

In my experience, this leads to the practical absence of hierarchies deeper than one level.

Too often, in other languages, you have the reflex, when you see that the concept A is a specialization of the concept B, to reify this fact by creating a class B and a class A as a subclass of B. Instead of creating your program around your data, you spend time reproducing the taxonomy of objects in your code, on the principle that this is reality.

In Go you can't define a general algorithm and specialize it. You must define a general algorithm and ensure it's general and works with the provided interface implementations.

Having been horrified by the growing complexity of some hierarchy trees on which the coders were making complex hacks to try to accommodate an algorithm whose logic finally implies all levels, I'd say I'm happy with the simpler Go logic, even if it forces you to think instead of just reifying the concepts of your application model.