What are Mixins (as a concept)

I'm trying to get my head around the Mixin concept but I can't seem to understand what it is. The way I see it is that it's a way to expand the capabilities of a class by using inheritance. I've read that people refer to them as "abstract subclasses". Can anyone explain why?

I'd appreciate if you'd explain your answer based on the following example (From one of my lecture slideshows):

Before going into what a mix-in is, it's useful to describe the problems it's trying to solve. Say you have a bunch of ideas or concepts you are trying to model. They may be related in some way but they are orthogonal for the most part -- meaning they can stand by themselves independently of each other. Now you might model this through inheritance and have each of those concepts derive from some common interface class. Then you provide concrete methods in the derived class that implements that interface.

The problem with this approach is that this design does not offer any clear intuitive way to take each of those concrete classes and combine them together.

The idea with mix-ins is to provide a bunch of primitive classes, where each of them models a basic orthogonal concept, and be able to stick them together to compose more complex classes with just the functionality you want -- sort of like legos. The primitive classes themselves are meant to be used as building blocks. This is extensible since later on you can add other primitive classes to the collection without affecting the existing ones.

Getting back to C++, a technique for doing this is using templates and inheritance. The basic idea here is you connect these building blocks together by providing them via the template parameter. You then chain them together, eg. via typedef, to form a new type containing the functionality you want.

Taking your example, let say we want to add a redo functionality on top. Here's how it might look like:

#include <iostream>
using namespace std;

struct Number
{
  typedef int value_type;
  int n;
  void set(int v) { n = v; }
  int get() const { return n; }
};

template <typename BASE, typename T = typename BASE::value_type>
struct Undoable : public BASE
{
  typedef T value_type;
  T before;
  void set(T v) { before = BASE::get(); BASE::set(v); }
  void undo() { BASE::set(before); }
};

template <typename BASE, typename T = typename BASE::value_type>
struct Redoable : public BASE
{
  typedef T value_type;
  T after;
  void set(T v) { after = v; BASE::set(v); }
  void redo() { BASE::set(after); }
};

typedef Redoable< Undoable<Number> > ReUndoableNumber;

int main()
{
  ReUndoableNumber mynum;
  mynum.set(42); mynum.set(84);
  cout << mynum.get() << '\n';  // 84
  mynum.undo();
  cout << mynum.get() << '\n';  // 42
  mynum.redo();
  cout << mynum.get() << '\n';  // back to 84
}

You'll notice I made a few changes from your original:

• The virtual functions really aren't necessary here because we know exactly what our composed class type is at compile-time.
• I've added a default value_type for the second template param to make its usage less cumbersome. This way you don't have to keep typing <foobar, int> everytime you stick a piece together.
• Instead of creating a new class that inherits from the pieces, a simple typedef is used.

Note that this is meant to be a simple example to illustrate the mix-in idea. So it doesn't take into account corner cases and funny usages. For example, performing an undo without ever setting a number probably won't behave as you might expect.

As a sidenote, you might also find this article helpful.

I like the answer from greatwolf, but would offer one point of caution.

greatwolf stated, "The virtual functions really aren't necessary here because we know exactly what our composed class type is at compile-time." Unfortunately, you can run into some inconsistent behavior if you use your object polymorphically.

Let me tweak the main function from his example:

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!
}  

By making the "set" function virtual, the proper override will be called and the inconsistent behavior above will not occur.

A mixin is a class dessigned to provide functionality for another class, normally through a specified class which provides the basic features that the functionality needs. For example, consider your example:
The mixin in this case provides the functionality of undoing the set operation of a value class. This hability is based on the get/set functionality provided by a parametrized class (The Number class, in your example).

Another example (Extracted from "Mixin-based programming in 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);
  }
... 
};

In this example, the mixin provides the functionality of counting vertices, given a graph class that performs trasversal operations.

Commonly, in C++ mixins are implemented through the CRTP idiom. This thread could be a good read about a mixin implementation in C++: https://stackoverflow.com/questions/7085265/what-is-c-mixin-style

Here is an example of a mixin that takes advantage of the CRTP idiom (Thanks to @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>
{
};

This mixin provides the functionality of heterogeneous copy to a set (hierarchy) of shape classes.

Mixins in C++ are expressed using the Curiously Recurring Template Pattern (CRTP). This post is an excellent breakdown of what they provide over other reuse techniques... compile-time polymorphism.

To understand the concept forget classes for a moment. Think (most popular) JavaScript. Where objects are dynamic arrays of methods and properties. Callable by their name as a symbol or as a string literal. How would you implement that in standard C++ in a year 2018? Not easily. But that is the core of the concept. In JavaScript one can add and remove (aka mix-in) whenever and whatever one wishes to. Very important: No class inheritance.

Now onto C++. Standard C++ has all you need, does not help as a statement here. Obviously I will not write a scripting language in order to implement mix-in using C++.

Yes, this is a good article , but for inspiration only. CRTP is not a panacea. And also the so called academic approach is here, also (in essence) CRTP based.

Before down-voting this answer perhaps consider my p.o.c. code on wand box :)

This works the same as an interface and maybe more so as an abstract, but interfaces are easier to get first time.

It addresses many issues but one I find in development that comes up a lot is external apis. imagine this.

You have a database of users, that database has a certain way of getting access to its data. now imagine you have facebook, that also has a certain way of getting access to its data (api).

at any point your application may need to run using data from facebook or your database. so what you do is create an interface that says "anything that implements me is going to definitely have the following methods" now you can implement that interface into your application...

because an interface promises that the implementing repositories will have the methods declared in them, you know that wherever or whenever you use that interface in your application, if you switch the data over, it's always going to have the methods you are defining and thus have data to work off of.

There are many more layers to this pattern of working, but the essence is that it is good because data or other such persistant items become a big part of your application, and if they change without you knowing, your application can break :)

Here's some pseudo code.

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.