Lorsque vous mangez un burrito, chacun de vos récepteurs gustatifs chante de joie. Chaque bouchée apporte une combinaison de différents types de saveurs, comme le salé, le sucré, l'épicé et l'umami. Chaque bouchée qui suit a un goût légèrement différent, car une nouvelle collection d'ingrédients réunit leurs saveurs.
Vous avez peut-être lu les ingrédients du menu, mais vous ne savez pas exactement comment la salsa est préparée. L'assaisonnement qu'ils utilisent sur leurs légumes pourrait être un mélange secret. Cependant, vous n'avez pas besoin de connaître chaque ingrédient exact. Il suffit de savoir que c'est délicieux.
Les ingrédients que vous connaissez, comme le riz blanc nature, sont concrets. Les autres éléments sont abstraits. Vous savez que c'est de la salsa, mais quel genre ? Ou, si quelqu'un vient de vous donner un burrito de nulle part, alors tout le burrito est abstrait.
Avec l'héritage, l'abstraction est un concept important dans la programmation orientée objet. La théorie est que chaque objet doit fournir des résultats simples et prévisibles. Les objets ne doivent également partager que ce qui doit être partagé.
Vous pouvez considérer un burrito comme un objet. À l'intérieur du burrito, vous avez plusieurs autres objets, comme des haricots, du riz, du fromage et de la sauce piquante. Les haricots peuvent avoir été assaisonnés. Le fromage pourrait être un mélange. Et la sauce piquante pourrait être une combinaison de piments vieillis au vinaigre.
Vous n'avez pas besoin de savoir comment tous les ingrédients d'un burrito ont été fabriqués. Et dans le cas des hot-dogs, vous ne voulez probablement pas le savoir. Tout ce qui compte, c'est qu'il ne se désagrège pas lorsque vous le mangez et qu'il est super savoureux.
C'est la même chose avec la programmation d'objets. Lorsque vous instanciez un objet (créez-le à partir d'une classe), c'est comme si vous commandiez un burrito au comptoir du food truck. Vous avez accès à certaines données, mais pas à toutes. Vous n'avez pas besoin de savoir comment fonctionne l'objet, tant que les fonctions renvoient les données correctes. Voici un burrito en JavaScript/Typescript :
classe CheeseBlend {
private _ingredients =["Colby Jack", "Cheddar", "Manchego"] ;
obtenir les ingrédients() {
retour "fromage fondu" ;
}
}
classe SecretSalsa {
private _ingredients =["oignons", "tomates", "coriandre", "Guatemalan Insanity Peppers"] ;
obtenir les ingrédients() {
return "c'est un secret" ;
}
}
classe Burrito {
private _beans ="haricots" ;
privé _riz ="riz" ;
private _cheese :CheeseBlend =new CheeseBlend();
private _salsa :SecretSalsa =new SecretSalsa();
obtenir du fromage() {
retourner this._cheese.ingredients ;
}
obtenir de la salsa() {
retourner this._salsa.ingredients ;
}
}
let burro =new Burrito();
console.log(burro.cheese);
console.log(burro.salsa);
Vous pouvez jouer avec ce code dans le bac à sable TypeScript.
Dans l'exemple ci-dessus, les ingrédients de la salsa et du fromage sont soustraits. Tout d'abord, ils sont encapsulés, pour cacher les ingrédients spéciaux. Ensuite, des getters sont ajoutés pour accéder aux ingrédients. Mais les ingrédients ne renvoient qu'une représentation abstraite de ce qu'ils sont réellement.
L'abstraction est cependant plus qu'un concept. Les cours peuvent aussi être abstraits. Cela signifie qu'ils peuvent définir d'autres classes. Mais ils ne peuvent pas être instanciés eux-mêmes.
Imaginez que vous allez au restaurant et que vous vous asseyez. Le serveur vous tend un menu. Vous l'ouvrez pour constater qu'il n'y a qu'un seul élément :de la nourriture.
C'est assez abstrait. Souhaitez-vous le commander? En mangeriez-vous ? Vous ne le feriez probablement pas. Dire que quelque chose est de la nourriture ne suffit pas. Il faut le décomposer en quelque chose de plus concret.
Et les pâtes ? Eh bien, c'est un type de nourriture plus spécifique. Et nous savons qu'il contient probablement des nouilles et de la sauce. Mais il existe de nombreuses sortes de pâtes différentes, donc c'est encore abstrait.
Fettuccine Alfredo est un exemple concret de nourriture et de pâtes. La même chose s'applique aux cours. Toutes les classes ne doivent pas être instanciées. Certaines classes ne doivent définir que la structure d'autres classes.
Voici un exemple avec un résumé Aliment classe, et un enfant MacadamiaNuts classe :
classe abstraite Nourriture {
constructeur (nom public :chaîne) {}
abstract totalCalories() :nombre ;
description abstraite() :chaîne ;
saveur abstraite() :chaîne ;
}
class MacadamiaNuts extend Nourriture {
constructeur() {
super ("Une tasse de noix de macadamia");
}
totalCalories() {
retour 962 ;
}
la description() {
return "Une noix d'Hawaï.";
}
saveur() {
retour "riche, beurré et noisette" ;
}
}
let noix =new MacadamiaNuts();
console.log(noix.nom)
console.log(nuts.description())
Voici le code.
Les classes abstraites indiquent aux autres classes comment elles sont censées se comporter. Dans l'exemple ci-dessus, si vous allez être une classe alimentaire, vous devez avoir des fonctions qui permettent d'accéder à votre nom, saveur, description et calories.
Notez que les Noix de Macadamia la classe s'étend Nourriture . C'est dire que MacadamiaNuts s'engage à respecter les règles de alimentation . Notez également que le constructeur appelle super . Cette commande instancie la classe parent avant que le constructeur n'instancie MacadamiaNuts .
Si vous apprenez à programmer, vous pouvez vous amuser davantage avec ces jeux de programmation.
Au début, les classes abstraites peuvent sembler inutiles. Après tout, vous ne pouvez pas les utiliser pour créer un objet. Et ce n'est pas comme s'ils transmettaient leurs fonctions. Les fonctions doivent être réécrites dans chaque classe enfant.
Il y a deux raisons principales pour lesquelles vous avez besoin de classes abstraites. Ils assurent la cohérence de votre code et s'assurent que les autres développeurs écrivent également du code cohérent. Vous ne travaillerez pas toujours seul. Toute l'équipe doit suivre les mêmes règles. Vous pouvez en savoir plus dans la documentation TypeScript sur les classes abstraites.