oop - smart - Mixin vs herencia
solidity español (8)
¿Cuál es la diferencia entre mixin y herencia?
¿Cuál es la diferencia entre mixin y herencia?
Una combinación es una clase base de la que puede heredar para proporcionar funcionalidad adicional. El nombre "mix-in" indica que está destinado a mezclarse con otro código. Como tal, la inferencia es que no crearías una instancia de la clase mix-in por sí mismo. Con frecuencia, la mezcla se usa con otras clases base. Por lo tanto, mixins es un subconjunto, o caso especial, de herencia.
Las ventajas de usar una combinación de herencia única son que puede escribir código para la funcionalidad una vez y luego usar la misma funcionalidad en múltiples clases diferentes. La desventaja es que puede necesitar buscar esa funcionalidad en otros lugares que no sean donde se usa, por lo que es bueno mitigar esa desventaja manteniéndola cerca.
Personalmente, he encontrado una combinación necesaria para usar sobre la herencia individual donde estamos probando un montón de código similar, pero los casos de prueba se instancian en función de su herencia de un caso base, y la única manera de mantener el código cerca en hand (y en el mismo módulo), sin interferir con los números de cobertura, es heredar de un objeto, y hacer que los casos secundarios hereden tanto de la base universal de casos de prueba como de la base personalizada que solo se aplica a ellos.
Mixins en comparación y contraste con clases base abstractas
Ambos son una forma de clase principal que no está destinada a ser instanciada.
Un mixin proporciona funcionalidad, pero no puede usarlo directamente. Un usuario tiene la intención de usarlo a través de una (sub) clase.
Una clase base abstracta proporciona una interfaz, pero sin funcionalidad utilizable. Un usuario está destinado a crear la funcionalidad llamada por la interfaz.
En Python, algunas clases en el módulo abc son ejemplos de clases principales que proporcionan funcionalidad a través de herencia e interfaces abstractas que deben ser implementadas por la subclase. Estas ideas no son mutuamente excluyentes.
Resumen
En pocas palabras, un mix-in es solo una clase base que no crearías por sí sola, y normalmente se usa como una clase base secundaria en herencia múltiple.
"Un mixin es un fragmento de una clase en el sentido de que está destinado a ser compuesto con otras clases o mixins". -DDJ
Un mixin es un fragmento de clase o código que no está destinado para uso independiente, sino que se supone que debes usarlo dentro de otra clase. Ya sea componiéndolo como un campo / variable miembro o como un segmento de código. Tengo la mayor exposición al más tarde. Es un poco mejor que copiar y pegar el código repetitivo.
Aquí hay un excelente artículo de DDJ que presenta el tema.
Half-Life 2 / "Source" SDK es un gran ejemplo de C ++ mixins. En ese entorno, las macros definen bloques de código considerables que se pueden agregar para dar a la clase un "sabor" o característica específica.
Mire el ejemplo de la wiki de fuentes: crear una entidad lógica . En el código de ejemplo, la macro DECLARE_CLASS se puede considerar mixin. Source SDK usa mixins ampliamente para estandarizar el código de acceso a datos y atribuir comportamientos a las entidades.
Con herencia múltiple, la nueva clase puede estar compuesta de múltiples superclases. Puede llamar solo a los métodos definidos en cualquiera de las superclases.
Por otro lado, mixin es una subclase abstracta que se puede usar para especializar el comportamiento de una variedad de clases para padres. Mixins puede llamar a un método (por ejemplo sayHello(): String ) aunque no definan dicho método.
mixin M {
name: String
defmethod greetings() { print sayHello() + " " + name}
}
Como puede ver, puede llamar a sayHello() aunque no esté definido en ninguna parte. Si agrega el mixin M a la clase C , la C debería proporcionar el método sayHello() .
Creo que es importante tener en cuenta que mixin no implica herencia . Según wikipedia, un Mixin es:
En los lenguajes de programación orientados a objetos, un mixin es una clase que contiene métodos para usar por otras clases sin tener que ser la clase padre de esas otras clases. La forma en que esas otras clases obtienen acceso a los métodos de mixin depende del idioma. Mixins a veces se describen como "incluido" en lugar de "heredado".
Específicamente, en un lenguaje como perl, mixins se puede agregar utilizando el módulo exportador:
package Mixins;
use Exporter qw(import);
our @EXPORT_OK = qw(pity);
# assumes it will be mixed-in to a class with a _who_do_i_pity method
sub pity {
my ($self) = @_;
printf("I pity %s/n", $self->_who_do_i_pity(''da foo''));
}
Que se puede combinar en cualquier módulo que contenga uno o más métodos a la vez:
package MrT
use Mixins qw(pity);
sub new {
return bless({}, shift);
}
sub _who_do_i_pity {
return ''da foo!''
}
Entonces en su módulo MrT se puede utilizar así:
use MrT;
MrT->new()->pity();
Sé que es un ejemplo absurdo, pero logra entender el tema ...
Mixin es un concepto abstracto y cualquier cosa que cumpla con sus requisitos se puede considerar como mixin.
Aquí hay una definición de Wikipedia.
En los lenguajes de programación orientados a objetos, un mixin es una clase que contiene métodos para usar por otras clases sin tener que ser la clase padre de esas otras clases. La forma en que esas otras clases obtienen acceso a los métodos de mixin depende del idioma. Mixins a veces se describen como "incluido" en lugar de "heredado".
En resumen, la diferencia clave de una herencia es que las mezclas no necesitan tener una relación "is-a" como en la herencia.
Desde el punto de vista de la implementación, puede pensarlo como una interfaz con implementaciones. Por ejemplo, una clase abstracta en Java podría considerarse como mixin si Java admite herencia múltiple.
Una mezcla en general se usa con herencia múltiple. Entonces, en ese sentido, no hay "diferencia".
El detalle es que una Mezcla rara vez es útil como un objeto independiente.
Por ejemplo, supongamos que tiene un nombre de combinación en "ColorAndDimension", que agrega una propiedad de color y ancho y alto.
Ahora, puedes agregar ColorAndDimension a, digamos, Shape Class, Sprite Class, Car Class, etc. Y todos tendrán la misma interfaz (por ejemplo, get / setColor, get / setHeight / Width, etc.)
Entonces, en el caso genérico, una mezcla en herencia IS. Pero se puede argumentar que es una cuestión de la función de la clase en el dominio general en cuanto a si una mezcla es una clase "primaria" o simplemente una mezcla.
Editar - solo para aclarar.
Sí, un Mix In puede considerarse, en la jerga moderna actual, una interfaz con una implementación asociada. En realidad, es una herencia simple, antigua y cotidiana, que utiliza una clase simple, antigua y cotidiana. Simplemente sucede que es una aplicación específica de MI. La mayoría de los idiomas no dan una combinación. En cualquier estado especial, es solo una clase que fue diseñada para ser "mezclada", en lugar de usarse de manera independiente.
mix-in es un caso específico y restringido de herencia (múltiple) utilizado para fines de implementación; algunos lenguajes (p. ej., Ruby) lo admiten sin admitir herencia múltiple generalizada.
tl; dr
mixin y herencia múltiple tienen la misma forma. Pero tienen una semántica diferente: mixin tiene las clases básicas que proporcionan la implementación de la función. Para la herencia, las clases base proporcionan la interfaz y la subclase tiene la implementación.
Pero de todos modos, la composición es preferible a mixin IMO