2009-05-13 35 views

Respuesta

15

mix-in es un caso específico y restringido de herencia (múltiple) utilizado para fines de implementación; algunos idiomas (por ejemplo, Ruby) lo admiten sin admitir herencia múltiple generalizada.

42

Una mezcla en general se utiliza con herencia múltiple. Entonces, en ese sentido, no hay "diferencia".

El detalle es que una mezcla en raras ocasiones es útil como 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, puede agregar ColorAndDimension a, por ejemplo, Clase de forma, Clase de Sprite, Clase de auto, etc. Y todos tendrán la misma interfaz (por ejemplo, obtener/establecerColor, obtener/establecerAltura/Ancho, etc.)

Por lo tanto, en el caso genérico, una herencia Mix in IS. Pero 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.

3

"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 una clase o fragmento de código que no está destinado para uso independiente, sino que se supone que debe usarse 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.

Here's a great DDJ article that introduces the subject.

El/SDK "Fuente" Half-Life 2 es un gran ejemplo de mixins C++. 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 origen: Authoring a Logical Entity. 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.

0

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 utilizar para especializar el comportamiento de una variedad de clases principales. 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 se puede ver, se puede llamar sayHello() a pesar de que no se define en cualquier lugar.Si agrega el mixin M a la clase C, el C debe proporcionar el método sayHello().

+1

no está seguro acerca de la exactitud de su primera declaración - clases pueden definir sus propios métodos – EugeneMi

15

¿Cuál es la diferencia entre mixin y herencia?

Un mezcla en es una clase base se puede heredar de 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 son un subconjunto, o caso especial, de herencia.

Las ventajas de utilizar una mezcla sobre herencia individual 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 en la que estamos probando un 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 que tiene a mano (y en el mismo módulo), sin interferir con los números de cobertura, es heredar de un objeto, y hacer que los casos hijo 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 las clases base abstractas

Ambos son una forma de clase padre que no se diseñó para ejecutarse.

A mixin proporciona funcionalidad, pero es incapaz de utilizar 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 la herencia y las interfaces abstractas que deben ser implementadas por la subclase. Estas ideas no son mutuamente excluyentes.

Resumen

En pocas palabras, una confusión en es sólo una clase base que no te instancia por su cuenta, y se utiliza típicamente como una clase base secundaria en la herencia múltiple.

0

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 su uso por otras clases sin tener que ser la clase padres de esas otras clases.La forma en que esas otras clases ganen el acceso a los métodos mixin depende del idioma. Los Mixins son a veces descritos como "incluidos" en lugar de "heredados".

Específicamente, en un lenguaje como Perl, mixins se pueden añadir 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 pueden mezclar-en a cualquier módulo que contiene uno, o más, método (s) a un tiempo:

package MrT 

use Mixins qw(pity); 

sub new { 
    return bless({}, shift); 
} 

sub _who_do_i_pity { 
    return 'da foo!' 
} 

Luego, en su módulo MrT se puede utilizar de esta manera:

use MrT; 

MrT->new()->pity(); 

Sé que es un ejemplo absurdo, pero tiene sentido ...

2

Mixin es un concepto abstracto y cualquier cosa que cumpla con sus requisitos se puede considerar como una mezcla.

Aquí hay una definición de Wikipedia.

En los lenguajes de programación orientados a objetos, 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.

+0

estoy teniendo un tiempo difícil entender la frase en negrita. Parece que "la diferencia (de B?) De A es que (B?) Necesita algo como en A". ¿Estás hablando de diferencia o similitud? – RayLuo

+0

@RayLuo Vaya ... Hice un error tipográfico. Perdon por confundirte. Los mix-ins NO necesitan tener una relación "is-a" – Alex

0

tl; dr

mixin y la 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 se prefiere sobre mixin OMI