# Mixin

En los lenguajes de programación orientada a objetos, un mixin es una clase que ofrece cierta funcionalidad para ser heredada por una subclase, pero no está ideada para ser autónoma. Heredar de un mixin no es una forma de especialización sino más bien un medio de obtener funcionalidad. Una subclase puede incluso escoger heredar gran parte o el total de su funcionalidad heredando de uno o más mixins mediante herencia múltiple.
Un mixin puede aplazar la definición y la vinculación de métodos hasta el tiempo de ejecución, aunque los atributos y los parámetros de instanciación siguen siendo definidos en tiempo de compilación. Esto se diferencia del enfoque más comúnmente utilizado, originario del lenguaje de programación Simula, en el que se definen todos los atributos, métodos e inicialización en tiempo de compilación.
Los mixins fueron utilizados por primera vez en Flavors, que era un enfoque a la orientación a objetos utilizado en Lisp Machine Lisp. La ventaja de los mixins es que fomentan la reutilización de código y evitan problemas típicos asociados con la herencia múltiple. Sin embargo, los mixins tienen sus propias limitaciones.

## Definición e implementación

En Simula, las clases son definidas en un bloque en que los atributos, métodos e inicialización de clase están definidas todos juntos; por lo que todos los métodos que pueden ser invocados en una clase están definidos juntos, y la definición de la clase es completa.
Con mixins, la definición de clase define solo los atributos y los parámetros asociados con esa clase; se deja que los métodos se definan en otro sitio, como en Flavors y CLOS, y son llamados «funciones genéricas». Estas funciones genéricas son funciones que están definidas en muchos casos por type dispatch.
Además de Flavors y CLOS, otros lenguajes que usan mixins son:
* D (llamados template mixins)
* Dart
* Dylan
* Javascript (Ember.js)
* Perl
* Python
* Racket (una implementación de Scheme)
* Ruby
* Scala
* Smalltalk
* Vala
* XOTcl (un sistema de objetos para Tcl)

## Ejemplo

En Python, el módulo SocketServer tiene las clases UDPServer y TCPServer que actúan como servidor de servidores socket UDP y TCP. Normalmente, todas las nuevas conexiones son manejadas dentro del mismo proceso. Además, hay dos clases mixin: ForkingMixIn y ThreadingMixIn. Extendiendo TCPServer con ThreadingMixIn de la siguiente forma,
la clase ThreadingMixIn añade funcionalidad al servidor TCP de forma que cada nueva conexión crea un nuevo hilo. Análogamente, el uso de ForkingMixIn haría que el proceso hiciese un fork para cada nueva conexión. Evidentemente, la funcionalidad de crear un nuevo hilo o un nuevo fork no es de gran utilidad como clase autónoma.
En este ejemplo de uso, los mixins ofrecen una funcionalidad esencial sin afectar la funcionalidad como servidor socket.

## Comentario

Parte de la funcionalidad de los mixins es ofrecida por interfaces en lenguajes populares como Java y C#. Sin embargo, puesto que una interfaz sólo específica a qué debe soportar la clase y no puede ofrecer una implementación, sólo es útil para ofrecer polimorfismo. Otra clase, ofreciendo una implementación y dependiente de la interfaz, sería útil para reprogramar un comportamiento común en un solo sitio.
Las interfaces, combinadas con programación orientada a aspectos, pueden crear mixins completos en lenguajes que soporten estas características, como C# o Java.
Los mixins aparecieron por primera vez en el sistema orientado a objetos simbólicos Flavors, y el nombre fue inspirado por la heladería Steve (Steve's Ice Cream Parlor), en Massachusetts. El propietario de la heladería ofrecía un sabor básico de helado (vainilla, chocolate, etc.) mezclado con una combinación de elementos (frutos secos, galletas, dulce de azúcar, etc.) y lo llamó «Mix-In», su propia marca registrada entonces.