If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.
closed as primarily opinion-based by GlenH7, Ampt, MichaelT, Bart van Ingen Schenau, Dan Pichelman Jul 3 at 22:26
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.
He means that where you'd use something on the order of:
in something like Java or C++, in Go you'd use (something equivalent to):
Yes, this provides inheritance-like capabilities. Let's expand the example above a little bit:
To do this, however, you use a syntax that's not allowed in C++ or Java -- you leave the embedded object without a name of its own, so it's more like:
This question/problem is kind of similar to this one.
In Go, you don't really have OOP.
If you want to "specialize" an object, you do it by embedding, which is a composition, but with some goodies making it partially similar to inheritance. You do it like this :
In this sample, ConnexionMysql is a kind of specialization of *sql.DB, and you can call on ConnexionMysql the functions defined on *sql.DB :
So at first sight you might think that this composition is the tool to make your usual taxonomy.
if a function defined on the *sql.DB calls other functions defined on *sql.DB, it won't call the functions redefined on ConnexionMysql even if they exist.
With classical inheritance, you often do something like this :
That is, you define
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.
You could do it like this using interfaces :
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.