Vidéo: 008 — Rappels, classes et héritage en Java 2024
Le concept d'héritage, et donc d'affacturage, en C ++ permet à une classe d'hériter des propriétés d'une classe de base. L'héritage a un certain nombre de buts; le principal avantage de l'héritage est la capacité de souligner la relation entre les classes. C'est ce que l'on appelle la relation IS_A - un four à micro-ondes IS_A et des trucs comme ça.
L'affacturage est une bonne chose si vous faites les corrélations correctes. Par exemple, la relation entre les micro-ondes et les fours conventionnels semble naturelle. Affirmez que le micro-ondes est un type de grille-pain spécial, et vous vous dirigez vers des problèmes. Certes, ils font tous les deux chaud, ils utilisent tous deux l'électricité, et ils sont tous les deux trouvés dans la cuisine, mais la similitude s'arrête là - un micro-ondes ne peut pas faire de pain grillé et un grille-pain ne peut pas faire de nachos.
L'identification des classes inhérentes à un problème et l'établissement des relations correctes entre ces classes est un processus connu sous le nom de affacturage. (Le mot est lié à l'arithmétique que vous avez été obligé de faire à l'école primaire: affiner les plus petits dénominateurs communs, par exemple, 12 est égal à 2 fois 2 fois 3.)
Voici comment vous pouvez utiliser héritage pour simplifier vos programmes en utilisant un exemple de compte bancaire. Supposons que l'on vous demande d'écrire un programme bancaire simple mettant en œuvre le concept de compte d'épargne et de compte chèque.
Les programmeurs orientés objet ont trouvé une manière concise de décrire les points saillants d'une classe dans un dessin. Les classes Vérification et Économies sont représentées sur cette figure. (Ceci n'est que l'une des façons d'exprimer graphiquement la même chose.)
Pour lire cette figure et les autres chiffres, rappelez-vous ce qui suit:
-
La grande boîte est la classe, avec le nom de la classe en haut.
-
Les noms dans les boîtes sont des fonctions membres.
-
Les noms qui ne sont pas dans les boîtes sont des membres de données.
-
Les noms qui sortent partiellement des boîtes sont des membres accessibles au public; c'est-à-dire que ces membres peuvent être accédés par des fonctions qui ne font pas partie de la classe ou de ses descendants. Les membres qui sont complètement dans la boîte ne sont pas accessibles depuis l'extérieur de la classe.
-
Une flèche épaisse représente la relation IS_A.
-
Une flèche fine représente la relation HAS_A.
Une voiture IS_A véhicule , mais une voiture HAS_A moteur .
Vous pouvez voir dans le premier chiffre que les classes Vérification et Epargne ont beaucoup en commun. Par exemple, les deux classes ont une fonction de membre de retrait () et de dépôt ().Comme les deux classes ne sont pas identiques, elles doivent rester séparées. (Dans une application bancaire de la vie réelle, les deux classes seraient beaucoup plus différentes que dans cet exemple.) Pourtant, il devrait y avoir un moyen d'éviter cette répétition.
Vous pourriez avoir une de ces classes héritée de l'autre. Les économies ont plus de membres que Vérification, , donc vous pouvez laisser Économies hériter de Vérification. Cette disposition est illustrée dans la figure suivante.
La classe Epargne hérite de tous les membres. La classe est complétée avec l'ajout du membre de données noWithdrawals et en surchargeant la fonction de retrait () . Vous devez annuler le retrait () car les règles de retrait d'argent d'un compte d'épargne sont différentes de celles pour retirer de l'argent d'un compte courant.
Même si Économies hérite de La vérification de est une économie de travail, mais elle n'est pas totalement satisfaisante. Le principal problème est que, comme le poids indiqué sur mon permis de conduire, il déforme la vérité. Cette relation d'héritage implique qu'un compte d'épargne est un type particulier de compte chèque, ce qui n'est pas le cas.
De telles fausses déclarations sont source de confusion pour le programmeur, à la fois aujourd'hui et demain. Un jour, un programmeur peu familier avec nos astuces de programmation devra lire et comprendre ce que fait notre code. Les représentations trompeuses sont difficiles à concilier et à comprendre.
De plus, de telles fausses déclarations peuvent entraîner des problèmes à l'avenir. Supposons, par exemple, que la banque change ses règles en matière de vérification des comptes. Dites qu'il décide de facturer des frais de service sur les comptes de chèques seulement si le solde minimum baisse en dessous d'une valeur donnée au cours du mois.
Un changement comme celui-ci peut être facilement manipulé avec un minimum de changements dans la classe Vérification. Vous devrez ajouter un nouveau membre de données à la classe Vérification pour garder trace du solde minimum pendant le mois. Allons-y et appelons-le minimumBalance.
Mais maintenant vous avez un problème. Parce que Économies hérite de Vérification, Économies obtient également ce nouveau membre de données. Il n'a aucune utilité pour ce membre parce que le solde minimum n'affecte pas les comptes d'épargne, donc il se trouve juste là. Souvenez-vous que chaque objet de compte de contrôle a ce membre supplémentaire minimumBalance . Un membre de données supplémentaire peut ne pas être un gros problème, mais il ajoute plus de confusion.
Des changements comme celui-ci s'accumulent. Aujourd'hui, c'est un membre supplémentaire des données - demain, c'est une fonction membre modifiée. Finalement, la classe de compte d'épargne porte beaucoup de bagages supplémentaires qui est applicable uniquement aux comptes chèques.
Maintenant, la banque revient et décide de changer une politique de compte d'épargne. Cela vous oblige à modifier certaines fonctions dans Vérification. Les modifications de ce type dans la classe de base se propagent automatiquement à la sous-classe, sauf si la fonction est déjà surchargée dans la sous-classe Économies.
Par exemple, supposons que la banque décide de donner des toasters pour chaque dépôt dans le compte courant. Sans que la banque (ou ses programmeurs) le sachent, les dépôts sur les comptes chèques entraîneraient automatiquement des dons de grille-pain. Sauf si vous êtes très prudent, les modifications apportées à Vérification peuvent apparaître de manière inattendue dans Économies.
Comment pouvez-vous éviter ces problèmes? Affirmer que Vérification est un cas particulier de Économies change mais ne résout pas notre problème. Ce dont vous avez besoin est une troisième classe (appelez-le compte, juste pour les grins) qui incarne les choses qui sont communes entre Vérification et Économies, comme montré ici.
Comment la création d'un nouveau compte résout-elle les problèmes? Tout d'abord, créer une nouvelle classe Account est une description plus précise du monde réel (quel qu'il soit). Bien sûr, il y a vraiment quelque chose de connu comme un compte. Les comptes d'épargne et les comptes chèques sont des cas particuliers de ce concept plus fondamental.
De plus, la classe Économies est isolée des modifications apportées à la classe Vérification (et vice versa). Si la banque instaure une modification fondamentale de tous les comptes, vous pouvez modifier Compte, et toutes les sous-classes hériteront automatiquement de la modification. Mais si la banque ne modifie sa politique que pour la vérification des comptes, vous pouvez modifier uniquement la classe de compte Vérification sans affecter Économies.
Ce processus d'élimination des propriétés communes de classes similaires est l'essence de l'affacturage de classe .
L'affacturage n'est légitime que si la relation d'héritage correspond à la réalité. Factoring ensemble une classe Mouse et Joystick parce qu'ils sont tous les deux des périphériques de pointage matériels est légitime. Factoring ensemble une classe Mouse et Display car ils font tous les deux des appels de système d'exploitation bas niveau ne l'est pas.
