17

I'm looking through various libraries, and seeing extend() pop up a lot, but I'm also seeing mixin() show up. YUI has both mixins and extensions.

What's the difference between these two concepts? When would I decide between a mixin and extending an object?

Thanks, Matt

Matt
  • 22,224
  • 25
  • 80
  • 116

4 Answers4

16

Mixins don't work with instanceof but extends do. Mixins allow multiple inheritance but by faking it, not by properly chaining the prototypes.

I'll show an Ext-JS example but the concept applies to any class library that provides mixins, they all just copy properties to the object instead of chaining the prototype.

Ext.define('Ext.Window', {
    extend: 'Ext.Panel',
    requires: 'Ext.Tool',
    mixins: {
        draggable: 'Ext.util.Draggable'
    }
});

Ext.Window instanceof Ext.Panel //true
Ext.Window instanceof Ext.util.Draggable // false

Mixins are a great way to add some functionality to an object without resorting to inheritance. If you have to inherit something to get some functionality, then you can't use functionality from two classes. Many people believe it's evil.

Ext-JS experienced that problem when they wanted to add Labelable functionality to FieldSet and others that were not input like fields. There was no way that it could benefit from the Labelable behavior inside Field since they couldn't extend Field since it had all the input behavior in it too.

Ruan Mendes
  • 90,375
  • 31
  • 153
  • 217
  • 1
    This answer is pretty specific to Ext.js and not applicable to many other JavaScript libraries (jQuery and Underscore are just two examples). – natlee75 Nov 15 '13 at 15:57
  • 1
    @natlee75 My answer is saying that mixins don't use the prototype chain, and it fails `instanceof` tests, Ext-JS is one implementation of them (they let you check if something is a mixin in a different way). As far as I know, jquery or underscore do not implement mixing by setting them in the prototype chain (they just copy properties). Your comment implies that jquery and underscore can have mixins that work correctly with instanceof? Please elaborate/ – Ruan Mendes Nov 15 '13 at 19:32
  • 2
    No, but their `extend` functions don't do either. Only "class libraries" (like `Ext.define`) use the "extend" term for prototypical inheritance. – Bergi Jul 15 '14 at 16:12
  • 1
    @Bergi ECMAScript 6 also uses [**extends** for prototypal inheritance](http://es6-features.org/#ClassInheritance) – Ruan Mendes Jun 15 '15 at 19:47
6

The extend method is pretty common among JavaScript libraries and is generally a method that simply allows the consuming code to add all "own" properties and methods of one or more objects onto a target object. The code is usually pretty straightforward: iterate over all the own keys of each argument beyond the first and copy the value stored there to the first argument.

"Mixin" refers to a design pattern in which you use one object as a sort of container for a particular set of properties and methods you want to share across many objects in your system. For example, you might have width and height getters and setters that could apply to all UI components in your application and so you would create, in the case of JavaScript, either a function that can be instantiated with "new" or an object literal that holds these methods. You could then use an "extend" type function to copy these methods onto any number of objects in your system.

Underscore has a mixin method that is essentially just an extend where all of the passed in objects' methods are added to the base underscore object for use in chaining. jQuery does a similar thing with its extend method of jQuery.fn.

Personally I like to keep extend as is, a "copy everything from these objects to this object" type behavior while having a separate mixin method that instead accepts only a single source object and then treats all further arguments as names of properties and methods to copy (if only the target and source are passed in with no further arguments then it just acts like a single-source extend).

e.g.

function mixin(target, source) {
    function copyProperty(key) {
        target[key] = source[key];
    }

    if (arguments.length > 2) {
        // If there are arguments beyond target and source then treat them as
        // keys of the specific properties/methods that should be copied over.
        Array.prototype.slice.call(arguments, 2).forEach(copyProperty);
    } else {
        // Otherwise copy all properties/methods from the source to the target.
        Object.keys(source).forEach(copyProperty);
    }
}
natlee75
  • 5,097
  • 3
  • 34
  • 39
  • 1
    Can you tell me why you would do `Array.prototype.slice.call(arguments, 2)` over `arguments.slice(2)`. Just want to know when it is more useful. Thanks in advance – cantfindaname88 Feb 05 '14 at 21:27
  • 3
    @cantfindaname88: `arguments`, while `Array`-like, is not an `Array` instance, so it has no `.slice()` method. – Andy E Mar 12 '14 at 20:35
2

You can definitely create mixins by using extends.

Mixins give all the benefits of multiple inheritance, without hierarchy (prototypal inheritance in JavaScript). They both allow you to reuse an interface (or set of functions) on multiple objects. With mixins don't encounter the "diamond problem" that you can run into with parent-child relationships.

The diamond problem occurs when a one object inherits the same function (or even function name) from two objects. Why? If one of those two objects modified the function, adding functionality (ie. in Java called "super"), JavaScript doesn't know how to interpret/combine the two methods anymore. Mixins are a way of avoiding this heirarchy. They define functionality that you can stick anywhere. Mixins also typically don't contain data of their own.

So I could, for instance, write a mixin with $.extend() in jQuery. var newmixin = $.extend({}, mixin1, mixin2) would combine two interfaces, and flatten them (overwrite name conflicts).

Here are 3 things to consider:

  1. Does the combination of the two interfaces have "hierarchy" ie. parent/child relationship. In JavaScript this would mean prototypal inheritance.
  2. Are the functions copied, or referenced? If the original method changes, will the inherited methods change as well?
  3. What happens when two methods of the same name are combined? And how are these conflicts dealt with?
Ryan Taylor
  • 12,559
  • 2
  • 39
  • 34
0

Edit for clarity: These are sometimes the same thing and sometimes not; mixin is a name of a pattern used for reusing functions between multiple objects, and extend is more the algorithm / method used to do so. There are cases where they are identical (for example underscores _.extend) and cases where they differ (backbone.js 's extend).

In the case where they differ extend would generally link the prototype to the object being extended, whereas mixin would copy a list of methods onto the target.

taxilian
  • 14,229
  • 4
  • 34
  • 73
  • Except when you want the behavior that two classes give you. Can't use inheritance for that unless you go into multiple inheritance, which has its own set of problems. – Ruan Mendes Sep 20 '12 at 13:00
  • I'm not sure how that's related, since extend and mixin aren't directly related to inheritance, etc, they are just a method for mimicking that behavior. – taxilian Mar 08 '16 at 20:36
  • I'm just explaining the case where they don't have the same behavior. – Ruan Mendes Mar 08 '16 at 20:38
  • Ahh, I see what you mean. I guess there are some libraries which use extend to link the prototype, which can only be done once, where a mixin would tend to copy it more on a one on one basis. Of course, not all libraries do this, so it's an important distinction to check for. – taxilian Mar 09 '16 at 18:47