Similares a los Traits, estas construcciones, que proveen la implementación de un conjunto de métodos, pueden ser combinadas y conforman un mecanismo de compartición de código complementario a las clases. Su principal diferencia con los Traits es que pueden definir y acceder a variables y su combinación no producen conflictos, ya que estos se resuelven automáticamente por un mecanismo de linearization.
Los Mixins tienen implementaciones en varios de los lenguajes más modernos, como ser Ruby, Scala (en el lenguaje se les dice trait, pero son mixins), Python y Groovy.
Gracias al mecanismo de linearization, los mixins resuelven el problema del rombo o diamante presente en la herencia múltiple, definiendo una precedencia entre los mixins que componen una clase dependiendo del orden de composición, es decir, si la clase C se compone de los mixins {A, B}, se tomarán los métodos de B en los casos en los que se presenten conflictos. Como consecuencia de esta decisión de diseño de los mixins, resultará diferente la composición {A, B} que {B, A}.
Un Mix-In es una subclase abstractas: como una subclase que no está ligada a ninguna superclase. Se puede “aplicar” a cualquier superclase (can be “mixed-in”)
Se puede ver como una refactorización de la herencia hacia una “chain of resposibilities”.
En Scala es posible, no sólo aplicar el mixin estáticamente en la jerarquía, sino también al instanciar un objeto particular. En este ejemplo vemos una alternativa al decorator basado en mixins: Stackable Trait Pattern
Home
Artículos
