Introduction to mixins
ActionScript, and its ancestor, JavaScript, are prototype-based languages. In a prototype-based language, you can change class definitions at runtime so that you can easily add functionality. You add methods of other classes to your custom class by accessing an instance of that custom class's prototype object.
Every ActionScript object has a prototype property that you use to add behaviors to your custom classes. Flash applies the methods and properties of the prototype object to all instances of that object. The data type of the prototype property is an object, which means that you can add any number of properties and methods to an object through its prototype object.
A mixin provides an easy way to dynamically add the methods of an existing class to a custom class without using inheritance. You mix in the class, and then add that class's members to the prototype object of the custom class. ActionScript does not support multiple inheritance, however, mixins let you add functionality to your custom classes that they would not normally be able to use when they are derived from other Flex classes.
The source of the word mixin is attributed to a popular 1970s MIT hangout, Steve's Ice Cream. Steve's made its own ice cream, and you could specify the base flavor such as chocolate or vanilla, plus add any additional ingredients like cookies, nuts, or candies. These additional ingredients were called mixins. The term was then used to describe the Symbolics Flavors system in which stand-alone classes were known as flavors and helper classes that were added were known as mixins.
A mixin is an atomic unit in an object-oriented language that adds functionality to another class. Generally, mixins are not meant to be used on their own, just as you would not order a bowl of nuts at an ice cream stand. Instead, they provide a small piece of specialized functionality that you can easily add to a base class. Examples of common functionality added with mixins include printing, screen rendering, and event dispatching.
In Flex, for example, you use mixins to add functionality such as event dispatching to a class that does not inherit from the EventDispatcher class. Also, when you write a custom DataProvider, you must implement the DataProvider class and override all the methods of the DataProvider API. As a result, you cannot inherit the functionality of another class such as the EventDispatcher. In this case, you mix in the EventDispatcher class so that you can call the dispatchEvent() method while still implementing the DataProvider's methods.
The following illustration shows the conceptual application of a mixed in class:
The Flex component architecture uses mixins in the following ways:
- EventDispatcher (mixes into UIObject, Validator and the service classes, among others)
- DataProvider (mixes into Array)
- DataSelector (mixes into ScrollSelectList)
Before writing a class that uses a mixin, you should carefully consider the fact that their use generally violates the principals of good object-oriented coding. Although mixins can be a simple and powerful way to add functionality to custom classes, they can also introduce dependencies and overhead that you can avoid by carefully designing your custom object hierarchy.
