Mixin vs Héritage
Fait partie de la section Programmation Orientée Objet du Journey Dart de Coddy — leçon 54 sur 110.
Maintenant que vous avez appris comment fonctionnent les mixins, clarifions quand les utiliser au lieu de l'héritage. La différence clé réside dans la relation qu'ils expriment.
L'héritage représente une relation « est-un ». Un Dog est un Animal. La sous-classe est une version spécialisée du parent, et vous ne pouvez étendre qu'une seule classe.
Les mixins, en revanche, représentent une relation « peut faire ». Un Dog peut nager, mais nager n'est pas ce qui définit un chien.
// Héritage : Dog EST un Animal
class Animal {
String name;
Animal(this.name);
}
class Dog extends Animal {
Dog(String name) : super(name);
}
// Mixin : Dog PEUT nager (mais n'est pas défini par la nage)
mixin Swimming {
void swim() => print('Swimming');
}
class Dog extends Animal with Swimming {
Dog(String name) : super(name);
}Utilisez l'héritage lorsque les classes partagent une identité fondamentale et que vous avez besoin de constructeurs dans le parent. Utilisez des mixins lorsque vous souhaitez ajouter des capacités à des classes qui ne partagent pas d'ancêtre commun.
| Caractéristique | Héritage | Mixin |
|---|---|---|
| Relation | est-un | peut-faire |
| Limite | Un seul parent uniquement | Plusieurs mixins |
| Constructeurs | Autorisé | Non autorisé |
| Cas d'utilisation | Spécialisation | Comportement partagé |
Le meilleur dans tout ça ? Vous pouvez combiner les deux : étendre une classe et y ajouter plusieurs capacités, ce qui donne à vos classes exactement les fonctionnalités dont elles ont besoin.
Défi
FacileConstruisons un système de travailleurs qui démontre quand utiliser l'héritage par rapport aux mixins. Vous allez créer une classe de base pour la relation « est un » (is-a) et des mixins pour les capacités « peut faire » (can-do), puis les combiner pour montrer comment les deux approches fonctionnent ensemble.
Vous organiserez votre code en trois fichiers :
worker.dart: Définissez votre classe de base qui établit l'identité fondamentale de tous les travailleurs :- Une classe
Workeravec les propriétésString nameetString department. Incluez un constructeur qui prend les deux valeurs. Ajoutez une méthodeintroduce()qui affiche'$name works in $department'
- Une classe
skills.dart: Définissez des mixins qui représentent les capacités que les travailleurs peuvent avoir (les relations « peut faire ») :- Un mixin
CanCodeavec une méthodewriteCode()qui affiche'Writing code...' - Un mixin
CanDesignavec une méthodecreateDesign()qui affiche'Creating design...' - Un mixin
CanManageavec une méthodeleadTeam()qui affiche'Leading the team...'
- Un mixin
main.dart: Importez les deux fichiers et créez des types de travailleurs spécialisés qui combinent l'héritage avec les mixins :- Une classe
Developerqui étendWorkeret utilise le mixinCanCode - Une classe
TechLeadqui étendWorkeret utilise les mixinsCanCodeetCanManage - Créez un
Developernommé'Alice'dans le département'Engineering' - Créez un
TechLeadnommé'Bob'dans le département'Engineering' - Pour Alice : appelez
introduce()puiswriteCode() - Affichez une ligne vide
- Pour Bob : appelez
introduce(), puiswriteCode(), puisleadTeam()
- Une classe
Remarquez comment Developer et TechLead sont tous deux des travailleurs (héritage), mais ils peuvent faire des choses différentes (mixins). Le TechLead combine plusieurs capacités sans avoir besoin d'héritage multiple.
Résultat attendu :
Alice works in Engineering
Writing code...
Bob works in Engineering
Writing code...
Leading the team...Aide-mémoire
L'héritage représente une relation "est-un" (une sous-classe est une version spécialisée du parent), tandis que les mixins représentent une relation "peut-faire" (ajout de capacités sans définir l'identité).
// Héritage : Dog EST un Animal
class Animal {
String name;
Animal(this.name);
}
class Dog extends Animal {
Dog(String name) : super(name);
}
// Mixin : Dog PEUT nager
mixin Swimming {
void swim() => print('Swimming');
}
class Dog extends Animal with Swimming {
Dog(String name) : super(name);
}| Caractéristique | Héritage | Mixin |
|---|---|---|
| Relation | est-un | peut-faire |
| Limite | Un seul parent | Plusieurs mixins |
| Constructeurs | Autorisé | Non autorisé |
| Cas d'utilisation | Spécialisation | Comportement partagé |
Vous pouvez combiner les deux approches - étendre une classe et mixer plusieurs capacités :
class TechLead extends Worker with CanCode, CanManage {
TechLead(String name, String department) : super(name, department);
}Essayez vous-même
import 'worker.dart';
import 'skills.dart';
// TODO: Créer une classe Developer qui étend Worker et utilise le mixin CanCode
// TODO: Créer une classe TechLead qui étend Worker et utilise les mixins CanCode et CanManage
void main() {
// TODO: Créer un Developer nommé 'Alice' dans le département 'Engineering'
// TODO: Appeler introduce() puis writeCode() pour Alice
// TODO: Afficher une ligne vide
// TODO: Créer un TechLead nommé 'Bob' dans le département 'Engineering'
// TODO: Appeler introduce(), writeCode(), puis leadTeam() pour Bob
}
Cette leçon comprend un petit quiz. Commencez la leçon pour y répondre et suivre votre progression.
Toutes les leçons de Programmation Orientée Objet
1Les bases de la POO
Fichiers externesBibliothèques et importsIntroduction à la POOClasses vs ObjetsLe mot-clé thisMéthodesVariables d'instanceBases des constructeursRécapitulatif - Calculatrice simple4Null Safety
Introduction à la Null SafetyNullable vs Non-NullableLes opérateurs ? et !Le mot-clé late et la Null SafetyLes opérateurs Null-AwareLa Null Safety dans les classesRécapitulatif - Système de profil utilisateur7Classes abstraites et Interfaces
Classes abstraitesMéthodes abstraitesInterfaces en DartInterfaces implicitesImplémentation vs ExtensionInterfaces multiplesRécapitulatif - Calculateur de formes10Collections et Génériques
Aperçu des List, Set et MapCollections Type-SafeClasses génériquesMéthodes génériquesContraintes de généricitéIterable & IteratorRécapitulatif - Stockage générique2Les constructeurs en Dart
Constructeur par défautConstructeurs nommésListes d'initialisationConstructeurs constantsConstructeurs factoryConstructeurs de redirectionRécapitulatif - Shape Builder5Encapsulation
Membres publics vs privésLa convention du préfixe _Visibilité au niveau de la bibliothèqueApprofondissement des Getters & SettersMasquage d'informationsRécapitulatif - Dossiers d'étudiants8Mixins
Introduction aux MixinsCréation de MixinsUtilisation de plusieurs MixinsLe mot-clé on dans les MixinsMixin vs HéritageMixin vs InterfaceRécapitulatif - Système Animal11Méthodes spéciales
Redéfinition de toString()Redéfinition de hashCode & ==Interface ComparableMéthode call()Redéfinition de noSuchMethodRécapitulatif - Collection personnalisée14Patrons de conception Partie 1
Introduction aux patrons de conceptionPatron SingletonPatron FabriquePatron ObservateurPatron Stratégie3Propriétés de classe
Membres d'instance vs statiquesChamps Final & ConstVariables LateMéthodes et champs statiquesGetters et SettersRécapitulatif - Gestionnaire de compte bancaire6Héritage
Bases de l'héritageLe mot-clé superRedéfinition de méthodeL'annotation @overrideLe mot-clé final pour les classesConstructeurs et héritageRécapitulatif - Hiérarchie des employés9Polymorphisme
Bases du polymorphismePolymorphisme via les interfacesVérification de type à l'exécutionLes opérateurs is & asMot-clé covariantRécapitulatif - Processeur de paiement12POO Asynchrone
Futures & async/awaitBases des StreamsStream ControllersConstructeurs asynchronesL'asynchrone dans les méthodes de classeRécapitulatif - Data Fetcher15Patrons de conception Partie 2
Patron CommandePatron AdaptateurPatron DécorateurPatron Méthode ModèlePatron ÉtatPatron CompositePatron Repository