Что такое миксины (как понятие)

mixin-это класс, назначенный для обеспечения функциональности для другого класса, обычно через указанный класс, который предоставляет основные функции, необходимые для функциональности. Например, рассмотрим ваш пример:
Mixin в этом случае предоставляет функциональность отмены операции set класса value. Эта hability основана на get/set функциональность, предоставляемая параметризованным классом (Number класса, в вашем примере).

другой пример (взято из "программирование на основе Mixin в C++"):

template <class Graph>
class Counting: public Graph {
  int nodes_visited, edges_visited;
public:
  Counting() : nodes_visited(0), edges_visited(0), Graph() { }
  node succ_node (node v) {
    nodes_visited++;
    return Graph::succ_node(v);
  }
  edge succ_edge (edge e) {
    edges_visited++;
    return Graph::succ_edge(e);
  }
... 
};

в этом примере mixin предоставляет функциональность подсчет вершин, учитывая класс графа, который выполняет операции trasversal.

обычно в C++ миксины реализуются через CRTP идиома. Этот поток может быть хорошим чтением о реализации mixin в C++:что такое C++ Mixin-стиль?

вот пример миксин, который использует идиому CRTP (благодаря @Simple):

#include <cassert>
#ifndef NDEBUG
#include <typeinfo>
#endif

class shape
{
public:
    shape* clone() const
    {
        shape* const p = do_clone();
        assert(p && "do_clone must not return a null pointer");
        assert(
            typeid(*p) == typeid(*this)
            && "do_clone must return a pointer to an object of the same type"
        );
        return p;
    }

private:
    virtual shape* do_clone() const = 0;
};

template<class D>
class cloneable_shape : public shape
{
private:
    virtual shape* do_clone() const
    {
        return new D(static_cast<D&>(*this));
    }
};

class triangle : public cloneable_shape<triangle>
{
};

class square : public cloneable_shape<square>
{
};

этот mixin обеспечивает функциональность неоднородная копия к набору (иерархии) классов фигур.

Мне нравится ответ от greatwolf, но я хотел бы предложить один пункт предостережения.

greatwolf заявил, что "виртуальные функции действительно не нужны здесь, потому что мы точно знаем, что наши составленный тип класса во время компиляции."К сожалению, вы можете столкнуться с некоторым непоследовательным поведением, если вы используете свой объект полиморфно.

позвольте мне настроить основную функцию из его примера:

int main()
{
  ReUndoableNumber mynum;
  Undoable<Number>* myUndoableNumPtr = &mynum;

  mynum.set(42);                // Uses ReUndoableNumber::set
  myUndoableNumPtr->set(84);    // Uses Undoable<Number>::set (ReUndoableNumber::after not set!)
  cout << mynum.get() << '\n';  // 84
  mynum.undo();
  cout << mynum.get() << '\n';  // 42
  mynum.redo();
  cout << mynum.get() << '\n';  // OOPS! Still 42!
}  

делая функцию" set " виртуальной, правильное переопределение будет вызывается и несогласованное поведение выше не произойдет.

Mixins в C++ выражаются с помощью Любопытно Повторяющийся Шаблон Шаблон (CRTP). этот пост - это отличное соотношение того, что они обеспечивают по сравнению с другими методами повторного использования... полиморфизм времени компиляции.

это работает так же, как интерфейс и, возможно, более абстрактно, но интерфейсы легче получить в первый раз.

он решает многие проблемы,но один я нахожу в разработке, которая приходит много внешних API. представьте себе это.

у вас есть база данных пользователей, что база данных имеет определенный способ получения доступа к своим данным. теперь представьте, что у вас есть facebook, который также имеет определенный способ получения доступа к своим данным (api).

в любой точке вашего приложение может потребоваться запустить с использованием данных из facebook или вашей базы данных. Итак, вы создаете интерфейс, который говорит: "все, что реализует меня, определенно будет иметь следующие методы" теперь вы можете реализовать этот интерфейс в своем приложении...

поскольку интерфейс обещает, что реализующие репозитории будут иметь методы, объявленные в них, вы знаете, что где бы или когда бы вы ни использовали этот интерфейс в своем приложении, если вы переключаете данные, это всегда будет иметь методы, которые вы определяете, и, следовательно, иметь данные для работы.

есть еще много слоев для этой модели работы, но суть в том, что это хорошо, потому что данные или другие такие устойчивые элементы становятся большой частью вашего приложения, и если они изменяются без вашего ведома, ваше приложение может сломаться:)

вот какой-то псевдокод.

interface IUserRepository
{
    User GetUser();
}

class DatabaseUserRepository : IUserRepository
{
    public User GetUser()
    {
        // Implement code for database
    }
}

class FacebookUserRepository : IUserRepository
{
    public User GetUser()
    {
        // Implement code for facebook
    }
}

class MyApplication
{
    private User user;

    MyApplication( IUserRepository repo )
    {
        user = repo;
    }
}

// your application can now trust that user declared in private scope to your application, will have access to a GetUser method, because if it isn't the interface will flag an error.

чтобы понять концепцию забудьте классы на мгновение. Подумайте (самый популярный) JavaScript. Где объекты являются динамическими массивами методов и свойств. Вызывается по их имени как символ или как строковый литерал. Как бы вы реализовали это в стандартном C++ в 2018 году? Не легко. Но это и есть суть концепции. В JavaScript можно добавлять и удалять (aka mix-in), когда и что угодно. Очень важно: нет наследования класса.

теперь на C++. Стандартный C++ имеет все, что вам нужно, не помогает в качестве заявления здесь. Очевидно, что я не буду писать язык сценариев для реализации mix-in с использованием C++.

да это хорошая статья, но только для вдохновения. CRTP не является панацеей. А также так называемый академический подход здесь, также (по существу) на основе CRTP.

перед голосованием этот ответ возможно рассмотрим мой p.o.C. код на палочке box :)