‫Dans cette leçon, vous apprendrez la différence critique entre les classes d'actifs et les interfaces lors de la
‫conception d'applications.
‫Il est essentiel de savoir quand utiliser une classe abstraite et quand utiliser une interface et quand n'utiliser aucune des
‫deux.
‫Les classes abstraites et les interfaces semblent similaires à certains égards, mais il existe des différences clés qui détermineront
‫quel est le meilleur choix pour ce que vous essayez d'accomplir.
‫Comprendre la différence entre une classe abstraite et une interface est très important, nous pouvons
‫donc être en mesure de concevoir des applications faiblement couplées et extensibles afin que nous puissions modifier et
‫changer facilement sans tout casser.
‫Nous discuterons de ces différences et de la façon de décider quand utiliser lesquelles dans cette vidéo.
‫Mais avant de faire cela, rafraîchissons d'abord notre mémoire sur les classes abstraites et les interfaces.
‫Donc tout d'abord, les classes abstraites et la classe abstraite sont une classe incomplète ou une classe qui ne peut pas être instanciée, ce qui signifie que nous ne
‫pouvons pas créer d'objets à partir de celle-ci.
‫Le but d'une classe abstraite est de fournir un modèle pour les classes dérivées et de définir des règles comme
‫ce que les classes dérivées doivent implémenter.
‫Mais pourquoi aurions-nous besoin qu'une classe soit marquée comme une classe abstraite pour commencer ?
‫Quel est le problème avec les cours réguliers?
‫Imaginez que nous ayons une moto de classe et une voiture de classe et qu'elles partagent certaines fonctionnalités pour réduire la redondance
‫du code.
‫Nous créons une classe de base appelée Vehicle pour empêcher la création d'instances de type véhicule et pour imposer à chaque
‫méthode d'implémenter sa version des méthodes de véhicule.
‫Nous devons le marquer comme une classe abstraite.
‫Nous pouvons tirer parti des classes abstraites pour concevoir des composants et spécifier un certain niveau de fonctionnalités communes qui
‫doivent être implémentées par les bonnes classes.
‫Alors rendons ce véhicule abstrait et tout ira bien.
‫Regardons maintenant à nouveau les interfaces.
‫Une interface est donc un contrat et elle ne peut contenir que des déclarations de méthode.
‫Il ne peut pas contenir de définitions de méthode.
‫Ils définissent une capacité qu'a une classe.
‫Imaginons que nous ayons trois classes.
‫Nous avons donc la classe, le vélo, la moto et la voiture.
‫Et puis nous voulons nous assurer que toutes ces classes héritent de ce véhicule de classe.
‫Et si vous souhaitez ajouter une fonctionnalité d'auto-conduite à notre voiture, par exemple, et que nous voulons créer
‫d'autres classes, par exemple, qui pourraient créer quelque chose comme un avion, cela n'a pas de sens d'ajouter la
‫fonctionnalité d'auto-conduite à le véhicule de la meilleure classe car toutes nos sous-classes n'auront pas cette
‫caractéristique.
‫Il serait plus pratique de l'ajouter sous la forme d'une interface appelée AI self-driving.
‫Ensuite, ces classes qui implémentent cette interface peuvent fournir la logique pour y parvenir.
‫Parlons maintenant des similitudes entre les interfaces et les classes abstraites, les interfaces et les classes
‫abstraites peuvent être instanciées.
‫Cela signifie que nous ne pouvons pas créer d'objets à partir d'eux.
‫Mais ils supportent tous les deux le polymorphisme, c'est-à-dire que l'on peut stocker un objet de type cad dans une variable de
‫type, classe abstraite animal.
‫Il en va de même pour les interfaces où l'on peut stocker n'importe quelle collection comme une liste ou une pile dans une variable
‫de type II énumérable.
‫Voyons maintenant les principales différences.
‫Une classe abstraite est conçue pour être héritée par des sous-classes qui implémentent ou remplacent ses méthodes.
‫En d'autres termes, les classes abstraites sont soit partiellement implémentées, soit pas du tout implémentées.
‫En revanche, les interfaces ne sont pas du tout implémentées.
‫Ensuite, une classe abstraite ne peut pas avoir de constructeur opposé à celui-ci.
‫Les classes abstraites peuvent avoir des constructeurs et des champs ainsi que des définitions de méthodes, et l'implémentation
‫sera de la responsabilité de la classe qui a implémenté l'interface.
‫D'un autre côté, une classe abstraite peut contenir une méthode, des définitions et des champs et les interfaces n'ont pas de constructeurs,
‫comme nous l'avons mentionné, elles ne peuvent pas non plus avoir de champs.
‫Alors maintenant, les classes peuvent implémenter de nombreuses interfaces, ce qui est un moyen d'obtenir une sorte d'héritage multiple.
‫Puisque teashop est un langage à héritage unique et ne le permet pas par défaut.
‫Pourtant, une classe ne peut hériter que d'une seule classe d'extension.
‫Ainsi, si une classe implémente une interface, elle doit implémenter tous ses membres, tels que les
‫propriétés, les méthodes, etc., d'autre part, lorsqu'une classe étend une classe abstraite, elle
‫doit implémenter ses membres abstraits uniquement pour qu'ils connaissent la partie non implémentée de la classe abstraite.
‫Regardons une analogie ici.
‫Imaginez un éditorial d'instructeur pointu où l'instructeur ne peut rien accomplir à moins qu'il ne soit un expert d'un sujet
‫ou qu'elle soit une experte d'un sujet parce que nous ne pouvons pas avoir d'instances de cours abstraits.
‫Ainsi, un instructeur devrait devenir un expert dans un sujet pour l'enseigner.
‫L'instructeur est donc devenu un expert en C dièse et maintenant il ou elle peut enseigner ces dièses à un moment donné, l'instructeur en C
‫dièse a dû éditer des vidéos, bien que tous les instructeurs n'aient pas besoin de faire la même chose.
‫Nous avons donc implémenté l'éditeur de vidéo de l'interface I pour que cela fonctionne.
‫Donc, tous les instructeurs n'ont pas besoin de pouvoir éditer, mais ceux qui implémentent cet éditeur vidéo
‫devront le faire.
‫D'accord.
‫Premièrement, si vous choisissez l'héritage sur une interface lors de la conception de la classe de boutique C, les bibliothèques utiliseront une
‫classe supplémentaire.
‫Si vous souhaitez certaines fonctionnalités, ce sont des sous-classes à avoir.
‫Par exemple, si vous avez un ensemble de fonctions, vous voulez que les sous-classes les mettent dans une classe
‫abstraite.
‫La classe abstraite est utilisée lorsque la classe dérivée partage ses propriétés fondamentales et son comportement de la classe abstraite,
‫le type de comportement qui définit réellement l'interface utilisateur de la classe.
‫Si vous souhaitez un contrat général sur un comportement ou une fonctionnalité, les interfaces sont généralement lâches par rapport
‫aux classes abstraites.
‫Vous ne voudriez pas utiliser des interfaces dans une situation où vous écrivez constamment le même code pour
‫toutes les méthodes d'interface.
‫Utiliser une classe abstraite et définir chaque méthode une fois.
‫Alors un petit résumé.
‫Lorsque nous parlons de classes abstraites, nous définissons les caractéristiques d'un type d'objet en précisant ce qu'est
‫un objet.
‫Lorsque nous parlons d'interface et définissons les capacités que nous avons promis de fournir, nous parlons
‫d'établir un contrat sur ce que l'objet peut faire.
‫Donc ce que l'objet est une classe abstraite, ce que l'objet peut faire.
‫Et interface.
‫Très bien, j'espère que vous avez apprécié et compris le résumé et cet aperçu des
‫deux types d'approches différentes.
‫Et maintenant, allons de l'avant et utilisons ces concepts et différents exemples tout au long des prochaines conférences et tout au long du
‫reste du cours.