是否为golang代码建立了已建立的模式名称，该名称似乎类似于mixin

Question

The gist https://gist.github.com/anonymous/68c3b072538ec48c2667f7db276e781b is a minimal simplified example of a repeated golang code pattern that I have encountered in an existing code base which I am trying to document. From its usage it appears to be similar to a mixin, but neither myself or any of my colleagues have actually seen this pattern before in golang. Can anyone tell me an appropriate established name for this pattern?

The gist attempts to illustrate:

• Unmodified behaviour implementation code (M's funcs) used by multiple types (A and B).
• Included by composition into a host type (A and B).
• Behaviour methods exported and accessible via a host.behaviour.method(...) call e.g. a.Formatter.FormatText(...).
• Host methods are acted upon by the behaviour.
• The behaviour holds state (private or exported) which modifies the execution of the behaviour.
• The type that has add a specific behaviour added can be used by a function needing that behaviour by passing the behaviour field e.g. b := NewB().Formatter.
• Many different behaviours can be composed into a given type (not actually shown for brevity, but you could imagine an M1, M2, M3, etc being included into A or B).

It does not seem to strictly satisfy much of the definitions for a mixin as it manipulates the host object in ways that were beyond M's knowledge when it was written (potentially modifying host state) and doesn't directly add methods to the host type:

• https://en.wikipedia.org/wiki/Mixin
• What is a mixin, and why are they useful?
• Mixins vs. Traits

And it doesn't seem to follow the same pattern as some self proclaimed 'golang mixins' I have found:

• https://gist.github.com/haazime/270657beb140a307a559
• https://gist.github.com/hasanozgan/2598e6abe80803e4573b
• Limited mixin-like behaviour by embedding (e.g. embedding sync.Mutex) https://groups.google.com/forum/#!topic/golang-nuts/lFWYE8UzBCg

Answer 1

What is a mixin?

A mixin is basically a piece of code to be included ('mixed in') to another:

// WARNING: Messy, untested C code ahead
// Illustrates mixins in a non-OO language.
// mixin_hasname.h
    char *name;
// mixin_hasname_impl.h
struct hasname_vtable { // Vtable for storing mixin functions. Saves a lot of memory in the long run, as only one vtable has to be defined per type.
    char *(*getname)(void *self);
};

#define CAT(X,Y) X##Y
#define CATX(X,Y) CAT(X,Y)
#define GEN_HASNAME_VTABLE(TYPENAME,PRENAME)\
static struct hasname_vtable {\
    .getname = CATX(PRENAME,getname)\
} CATX(PRENAME,vtable);\
static char *CATX(PRENAME,getname)(void *self) {\
    return ((TYPENAME *)self)->name;\
}
// main.c
struct my_c_struct {
// include our mixin fields
#include <mixin_hasname.h>
    int x, y, z;
};

// include our mixin implementation
#include <mixin_hasname_impl.h>

// generate an implementation for our struct
GEN_HASNAME_VTABLE(struct my_c_struct, mycstruct_)

int indirect(struct my_c_struct *x, struct hasname_vtable *hasname_vt) {
    printf("%s
", hasname_vt.getname(x));
}

int main(void) {
    struct my_c_struct x;

    x.name = "Name";
    x.x = 0, x.y = 0, x.z = 0;

    printf("%s
", mycstruct_getname(&x)); // Notice we never had to define mycstruct_getname ourselves; we avoided code duplication
    indirect(&x, mycstruct_vtable); // Generally, vtables are passed. Some languages pass typeid's or function pointers, however. (Few put their vtable in their data type (in this case `x`) because of the inefficient memory usage. In the case of C, though, it saves you from having to pass your vtable everytime you call an indirect function).

    return 0;
}

This also holds true for a mixin in OOP, but OOP adds a lot of restrictions on mixins. For example, mixins might not have access to private variables, child class members, class methods, etc. Golang is not really OO.

Can this code pattern be called a mixin?

So, with that out of the way, is this an example of a mixin? No, I wouldn't say so. The biggest problem I'm having with answering that question isn't that your pattern doesn't follow the definition defined for OO (Because Golang is not OO anyway), but that it doesn't really 'mix in' the code, it's just storing it in it's own field.

struct struct_with_name_field {
    char *name;
}
// main.c
struct my_c_struct {
    struct struct_with_name_field namefield;
    int x, y, z;
}

int main(void) {
    struct my_c_struct x;

    x.namefield.name = "Name";
    x.x = 0, x.y = 0, x.z = 0;

    return 0;
}

However, I do think it's perfectly reasonable to call this pattern a mixin within your team or your documentation, especially because, as far as I know, real mixins aren't possible in Golang anyway, and this pattern is as close as you will get.

Summary

Golang doesn't allow you to define mixins (only interfaces), so your pattern isn't a mixin. However, given the definition of mixin (Especially outside OOP), and the fact that your pattern is probably the closest you will get to mixins in Golang, it is very reasonable to call this a mixin anyway.