Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

From Less is Exponentially More

If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.

share|improve this question

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.

2 Answers 2

up vote 12 down vote accepted

He means that where you'd use something on the order of:

class A : public B {};

in something like Java or C++, in Go you'd use (something equivalent to):

class A {
    B b;
};

Yes, this provides inheritance-like capabilities. Let's expand the example above a little bit:

struct B {
    int foo() {}
};

struct A { 
    B b;
};

A a;

a.foo();  // not allowed in C++ or Java, but allowed in Go.

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:

struct A {
   B;
};
share|improve this answer
1  
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 Coffin Jul 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. –  dystroy Jul 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 Coffin Jul 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 Coffin Jul 18 '12 at 16:18

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 :

type ConnexionMysql struct {
    *sql.DB
}

In this sample, ConnexionMysql is a kind of specialization of *sql.DB, and you can call on ConnexionMysql the functions defined on *sql.DB :

type BaseMysql struct {
    user     string
    password string
    database string
}

func (store *BaseMysql) DB() (ConnexionMysql, error) {
    db, err := sql.Open("mymysql", store.database+"/"+store.user+"/"+store.password)
    return ConnexionMysql{db}, err
}

func (con ConnexionMysql) EtatBraldun(idBraldun uint) (*EtatBraldun, error) {
    row := con.QueryRow("select pv, pvmax, pa, tour, dla, faim from compte where id=?", idBraldun)
    // stuff
    return nil, err
}

// somewhere else:
con, err := ms.bd.DB()
defer con.Close()
// ...
somethings, err = con.EtatBraldun(id)

So at first sight you might think that this composition is the tool to make your usual taxonomy.

But

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 :

func (db *sql.DB) doComplexThing() {
   db.doSimpleThing()
   db.doAnotherSimpleThing()
}

func (db *sql.DB) doSimpleThing() {
   // standard implementation, that we expect to override
}

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.

You could do it like this using interfaces :

type interface SimpleThingDoer {
   doSimpleThing()
   doAnotherSimpleThing()
}

func doComplexThing(db SimpleThingDoer) {
   db.doSimpleThing()
   db.doAnotherSimpleThing()
}

func (db *sql.DB) doSimpleThing() {
   // standard implementation, that we expect to override
}

func (db ConnexionMySQL) doSimpleThing() {
   // other implemenation
}

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.