Un mixage est généralement utilisé avec plusieurs héritages. Donc, dans ce sens, il n'y a "pas de différence".
Le détail est qu'un mixage est rarement utile en tant qu'objet autonome.
Par exemple, supposons que vous ayez un nom Mix In "ColorAndDimension", qui ajoute une propriété de couleur ainsi que la largeur et la hauteur.
Maintenant, vous pouvez ajouter ColorAndDimension à une classe de forme, à une classe de sprite, à une classe de voiture, etc. Et ils auront tous la même interface (disons get/setColor, get/setHeight/Width, etc.)
Ainsi, dans le cas générique, un héritage Mix in IS. Mais vous pouvez affirmer que le rôle de la classe dans le domaine global est de savoir si un mixage est une classe "primaire" ou simplement un mixage.
Modifier - juste pour clarifier.
Oui, un Mix In peut être considéré, dans le jargon moderne, une interface avec une implémentation associée. Il s’agit simplement d’un patrimoine simple, ancien et quotidien utilisant une classe ordinaire et ancienne. Il se trouve qu'il s'agit simplement d'une application spécifique de MI. La plupart des langues ne donnent pas un mélange Dans n'importe quel statut spécial, c'est juste une classe qui a été conçue pour être "mélangée", plutôt que utilisée seule.
Quelle est la différence entre un mixin et un héritage?
Une mix-in est une classe de base dont vous pouvez hériter pour fournir des fonctionnalités supplémentaires. Le nom "mix-in" indique qu'il est destiné à être mélangé avec un autre code. En tant que tel, on en déduit que vous n'instancieriez pas la classe mixte de manière autonome. Le mix-in est fréquemment utilisé avec d'autres classes de base. Par conséquent, (les mixins sont un sous-ensemble ou un cas particulier de l'héritage.} _
L'utilisation d'un mélange sur un héritage unique présente l'avantage de pouvoir écrire du code pour la fonctionnalité une fois, puis d'utiliser la même fonctionnalité dans plusieurs classes différentes. L'inconvénient est que vous devrez peut-être rechercher cette fonctionnalité ailleurs que là où elle est utilisée. Il est donc judicieux d'atténuer cet inconvénient en la gardant à proximité.
J'ai personnellement trouvé un mélange nécessaire à utiliser sur un seul héritage où nous soumettons beaucoup de code similaire, mais les cas de test sont instanciés sur la base de leur héritage d'un cas de base, et le seul moyen de garder le code à proximité hand (et dans le même module), sans modifier les numéros de couverture, consiste à hériter d'un objet et à faire en sorte que les cas enfants héritent à la fois de la base de test universelle et de la base personnalisée qui ne s'applique qu'à eux.
Mixins en comparaison et contraste avec des classes de base abstraites
Les deux sont une forme de classe parent qui n'est pas destinée à être instanciée.
Un mixin fournit des fonctionnalités mais ne peut pas l'utiliser directement. Un utilisateur est destiné à l'utiliser via une (sous) classe.
Une classe de base abstraite fournit une interface, mais sans fonctionnalité utilisable. Un utilisateur est destiné à créer la fonctionnalité appelée par l'interface.
En Python, certaines classes du module abc sont des exemples de classes parent qui fournissent toutes les deux des fonctionnalités via des interfaces d'héritage et des interfaces abstraites devant être implémentées par la sous-classe. Ces idées ne sont pas mutuellement exclusives.
Résumé
En termes simples, un mix-in est simplement une classe de base que vous ne voudriez pas instancier par elle-même, et est généralement utilisé comme classe de base secondaire dans un héritage multiple.
le mixage est un cas spécifique et restreint d'héritage (multiple) utilisé à des fins de mise en œuvre; certaines langues (par exemple, Ruby) le prennent en charge sans prendre en charge l’héritage multiple généralisé.
Mixin est un concept abstrait et tout ce qui répond à ses exigences peut être considéré comme un mixin.
Voici une définition de Wikipedia.
Dans les langages de programmation orientés objet, un mixin est une classe qui contient des méthodes utilisables par d'autres classes sans qu'il soit nécessaire que ce soit la classe parente de ces autres classes. La manière dont ces autres classes accèdent aux méthodes du mixin dépend de la langue. Les mixins sont parfois décrits comme étant "inclus" plutôt que "hérités".
En bref, la principale différence par rapport à un héritage est que les mix-ins n'ont PAS besoin d'avoir une relation "est-a" comme dans un héritage.
Du point de vue de l'implémentation, vous pouvez le penser comme une interface avec des implémentations. Par exemple, une classe abstraite en Java peut être considérée comme une combinaison si Java prend en charge l'héritage multiple.
"Un mixin est un fragment de classe dans le sens où il est destiné à être composé avec d'autres classes ou mixins." -DDJ
Un mixin est un fragment de classe ou de code qui n'est pas destiné à une utilisation autonome, mais que vous êtes supposé utiliser dans une autre classe. Composez-le comme un champ membre/variable ou comme un segment de code. J'ai le plus d'exposition au plus tard. C'est un peu mieux que copier-coller du code standard.
Voici un excellent article DDJ qui introduit le sujet.
Le SDK Half-Life 2/"Source" est un excellent exemple de mixins C++. Dans cet environnement, les macros définissent des blocs de code volumineux pouvant être ajoutés pour donner à la classe une "saveur" ou une fonctionnalité spécifique.
Regardez l'exemple du wiki source: Création d'une entité logique . Dans l'exemple de code, la macro DECLARE_CLASS peut être considérée comme un mixin. Le SDK source utilise beaucoup de mixins pour normaliser le code d'accès aux données et attribuer des comportements à des entités.
Avec l'héritage multiple, la nouvelle classe peut être composée de plusieurs super-classes. Vous ne pouvez appeler que des méthodes définies dans l'une des superclasses.
D'autre part, mixin est une sous-classe abstraite qui peut être utilisée pour spécialiser le contenu d'une variété de classes parentes. Les mixins peuvent appeler une méthode (par exemple sayHello(): String) même s'ils ne définissent pas une telle méthode.
mixin M {
name: String
defmethod greetings() { print sayHello() + " " + name}
}
Comme vous le voyez, vous pouvez appeler sayHello() même s’il n’est défini nulle part. Si vous ajoutez le mixin M à la classe C, le C doit fournir la méthode sayHello().
tl; dr
mixin et l'héritage multiple ont la même forme. Mais ayez une sémantique différente: mixin a les classes de base qui assurent la mise en oeuvre de la fonction Pour l'héritage, les classes de base fournissent l'interface et la sous-classe a l'implémentation.
Quoi qu'il en soit, la composition est préférable à mixin IMO
Je pense qu'il est important de noter que mixin n'implique pas inheritance. Selon wikipedia, un Mixin est:
Dans les langages de programmation orientés objet, un mixin est une classe qui contient des méthodes utilisables par d’autres classes sans être le classe parente de ces autres classes. Comment ces autres classes gagnent l'accès aux méthodes du mixin dépend de la langue. Les mixins sont parfois décrit comme étant "inclus" plutôt que "hérité".
Plus précisément, dans un langage comme Perl, des mixins peuvent être ajoutés à l'aide du module Exporter:
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'));
}
Ce qui peut être mélangé à n’importe quel module contenant une ou plusieurs méthodes à la fois:
package MrT
use Mixins qw(pity);
sub new {
return bless({}, shift);
}
sub _who_do_i_pity {
return 'da foo!'
}
Dans votre module MrT, vous pouvez alors utiliser:
use MrT;
MrT->new()->pity();
Je sais que c'est un exemple absurde, mais, ça passe au clair ...