Mixin vs inheritance

A mixin is typically used with multiple inheritance. So, in that sense, there's "no difference".

The detail is that a mixin is rarely useful as a standalone object.

For example, say you have a mixin named "ColorAndDimension", which adds a color property and width and height.

Now, you could add ColorAndDimension to a, say, Shape class, a Sprite class, a Car class, etc. And they will all have the same interface (say get/setColor, get/setHeight/Width, etc.)

So, in the generic case a mixin IS inheritance. But you can argue it's a matter of the role of the class in the overall domain as to whether a mixin is a "primary" class or simply a mixin.

Edit -- just to clarify.

Yes, a mixin can be considered, in today's modern lingo, an Interface with an associated Implementation. It really is just plain, old, everyday multiple inheritance using a plain, old, everyday class. It just happens to be a specific application of MI. Most languages don't give a mixin any special status; it's just a class that was designed to be "mixed in", rather than used standalone.

mix-in is a specific, restricted case of (multiple) inheritance used for implementation purposes; some languages (e.g. Ruby) support it without supporting generalized multiple inheritance.

"A mixin is a fragment of a class in the sense that it is intended to be composed with other classes or mixins." -DDJ

A mixin is a class or code fragment which is not intended for stand-alone use, but instead you're supposed to use it inside of another class. Either composing it as a member field/variable or as a code segment. I have the most exposure to the later. It's a little better than copy-pasting boilerplate code.

Here's a great DDJ article that introduces the subject.

The Half-Life 2 / "Source" SDK is a great example of C++ mixins. In that environment macros define sizable blocks of code which can be added to give the class a specific "flavor" or feature.

Look at the Source wiki example: Authoring a Logical Entity. In the example code the DECLARE_CLASS macro can be considered a mixin. Source SDK uses mixins extensively to standardize the data-access code and ascribe behaviors to entities.

Mixins are vastly used in a more "plugin" like manner.

They are the same but in a different context each one of them. Usually when we talk about inheritance we are talking about SINGLE inheritance, and a mixin is a construct that allows MULTIPLE inheritance.

This is a language construct that is highly controversial in the OOP world because of:

• The ambiguity that it must be resolved
• A lot of the time "mixin" classes don't work on its own, and may conflict with other mixins
• It can result in a "diamond inheritance problem", where two super classes can inherit from the same class

But that aside, is a powerful construct that's used in various languages and frameworks, some examples are:

• Django

  • https://github.com/django/django/blob/98126cdfaf632abc8f0b5e65910e46a4eedc4641/django/views/generic/list.py#L194

  • https://docs.djangoproject.com/en/3.1/topics/class-based-views/mixins/

• Typescript
  • https://www.typescriptlang.org/docs/handbook/mixins.html
  • https://vincit.github.io/objection.js/guide/plugins.html#_3rd-party-plugins

With multiple inheritance, new class may be composed from multiple superclasses. You can call only methods defined in any of superclasses.

On the other hand, mixin is an abstract subclass that may be used to specialize the beavior of a variety of parent classes. Mixins may call a method (for example sayHello(): String) even though they do not define such a method.

mixin M {
    name: String
    defmethod greetings() { print sayHello() + " " + name}
}

As you see, you can call sayHello() even though it is not defined anywhere. If you add the mixin M to class C, the C should provide the sayHello() method.