Polymorphisme via les interfaces
Fait partie de la section Programmation Orientée Objet du Journey Dart de Coddy — leçon 58 sur 110.
Dans la leçon précédente, vous avez vu le polymorphisme par l'héritage - en utilisant un type de classe parente pour travailler avec des objets enfants. Mais le polymorphisme fonctionne également via les interfaces, et cette approche est souvent plus flexible.
Lorsque des classes implémentent la même interface, vous pouvez les traiter de manière polymorphe même si elles n'ont aucune relation d'héritage :
abstract class Printable {
void printDetails();
}
class Invoice implements Printable {
@override
void printDetails() => print('Invoice #1234');
}
class Report implements Printable {
@override
void printDetails() => print('Monthly Report');
}
class Receipt implements Printable {
@override
void printDetails() => print('Receipt for purchase');
}
void printAll(List<Printable> items) {
for (var item in items) {
item.printDetails();
}
}
void main() {
var documents = [Invoice(), Report(), Receipt()];
printAll(documents);
}Invoice, Report et Receipt sont des classes totalement indépendantes - elles ne partagent pas de parent. Pourtant, parce qu'elles implémentent toutes Printable, nous pouvons les stocker dans la même liste et appeler printDetails() sur chacune d'elles.
C'est puissant car cela vous permet de définir des contrats de comportement sans imposer une hiérarchie d'héritage. N'importe quelle classe peut implémenter une interface, quel que soit ce qu'elle étend. Votre code devient plus modulaire puisque vous pouvez ajouter de nouveaux types imprimables sans modifier le code existant - il suffit d'implémenter l'interface.
Défi
FacileConstruisons un système de lecteur multimédia qui démontre le polymorphisme à travers les interfaces. Vous allez créer une interface qui définit ce que signifie être « jouable », puis implémenter plusieurs types de médias non liés qui remplissent tous ce contrat - ce qui permet de les manipuler de manière uniforme malgré l'absence de relation d'héritage.
Vous organiserez votre code en deux fichiers :
media.dart: Définissez votre interface et vos classes de médias ici :- Une classe abstraite
Playableavec deux méthodes abstraites :play()etString getMediaType() - Une classe
Songqui implémentePlayable. Elle doit avoir unString titleet unString artist. Sa méthodeplay()affichePlaying song: [title] by [artist]etgetMediaType()retourne'Audio' - Une classe
Videoqui implémentePlayable. Elle doit avoir unString titleet unint duration(en minutes). Sa méthodeplay()affichePlaying video: [title] ([duration] min)etgetMediaType()retourne'Video' - Une classe
Podcastqui implémentePlayable. Elle doit avoir unString titleet unint episode. Sa méthodeplay()affichePlaying podcast: [title] - Episode [episode]etgetMediaType()retourne'Podcast'
playAll(List<Playable> playlist)qui parcourt la liste et, pour chaque élément, affiche[Media Type]:suivi de l'appel deplay()sur cet élément.- Une classe abstraite
main.dart: Importez votre fichier média et démontrez le polymorphisme basé sur l'interface :- Créez une
List<Playable>contenant uneSongavec le titre'Imagine'et l'artiste'John Lennon', uneVideoavec le titre'Dart Tutorial'et la durée15, et unPodcastavec le titre'Tech Talk'et l'épisode42 - Passez cette liste à
playAll()
- Créez une
Remarquez comment Song, Video et Podcast ne partagent aucune classe parente - ce sont des types complètement distincts. Pourtant, parce qu'ils implémentent tous Playable, vous pouvez les stocker dans la même liste et les traiter de manière uniforme via l'interface.
Sortie attendue :
Audio:
Playing song: Imagine by John Lennon
Video:
Playing video: Dart Tutorial (15 min)
Podcast:
Playing podcast: Tech Talk - Episode 42Aide-mémoire
Le polymorphisme fonctionne via des interfaces, permettant à des classes non liées d'être traitées de manière uniforme sans relations d'héritage.
Les classes implémentant la même interface peuvent être utilisées de manière polymorphe :
abstract class Printable {
void printDetails();
}
class Invoice implements Printable {
@override
void printDetails() => print('Invoice #1234');
}
class Report implements Printable {
@override
void printDetails() => print('Monthly Report');
}
void printAll(List<Printable> items) {
for (var item in items) {
item.printDetails();
}
}
void main() {
var documents = [Invoice(), Report()];
printAll(documents);
}Le polymorphisme basé sur les interfaces vous permet de :
- Définir des contrats de comportement sans imposer de hiérarchies d'héritage
- Stocker des types non liés dans la même collection
- Ajouter de nouveaux types sans modifier le code existant
- Rendre le code plus modulaire et flexible
Essayez vous-même
import 'media.dart';
void main() {
// TODO: Créer une List<Playable> contenant :
// - Une Song avec le titre 'Imagine' et l'artiste 'John Lennon'
// - Une Video avec le titre 'Dart Tutorial' et la durée 15
// - Un Podcast avec le titre 'Tech Talk' et l'épisode 42
// TODO: Passer la liste à playAll()
}
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