Dus we hebben het gehad over inkapseling, over abstractie, hoe zit het met de derde pijler
van hoop, het heet overerving en overerving stelt nieuwe objecten in staat de eigenschappen van bestaande objecten over te nemen, zodat
je klassen kunt erven.
Laten we een voorbeeld bekijken.
Laten we de vorige code die we hadden verwijderen en teruggaan naar ons spelvoorbeeld.
We willen een nieuw spel maken en we hebben verschillende soorten gebruikers, dus we hebben gebruikers die tovenaars kunnen zijn, dat kunnen
elfen zijn, dat kunnen, ik weet het niet, boogschutters zijn.
Maar al deze gebruikers hebben een aantal gemeenschappelijke functies.
En elk van de subgebruikers, zoals tovenaars, elven, boogschutters, heeft een aantal gemeenschappelijke gedeelde functionaliteit, maar aan de
andere kant, misschien verschillende aanvallen.
Dus met OLP kunnen we echt overerving doen.
Laten we bijvoorbeeld zeggen dat we hier een klasgebruiker hebben en deze gebruiker zal, laten we zeggen, een ondertekenfunctie hebben.
Of de Sinon-methode, nogmaals, het gaat zichzelf ontvangen en dan gaan we er voorlopig maar vanuit dat we hier
een soort teken hebben.
Dus laten we voor nu zeggen: print ingelogd, want om een game te spelen, moeten ze ingelogd zijn.
OK, nu vraag je je misschien af, oh, waar is de init-methode hier?
Zouden we niet die init-methode moeten hebben die als eerste wordt uitgevoerd?
Dat zou kunnen, maar als we geen variabelen of attributen hebben die we aan de gebruiker willen toewijzen, in dat geval zouden
we een behoefte en een methode hebben.
Dus voor nu zeggen we gewoon dat we niets nodig hebben dat de gebruiker heeft behalve
deze aanmeldingsmethode.
Laten we nu zeggen dat we een aantal subklassen willen maken, zodat we een klassenwizard hebben.
En voor nu doen we hier gewoon een pas, zodat we geen lege klas hebben, maar het stelt ons nog steeds in staat om het
te bouwen.
En laten we zeggen dat we ook een klas hebben.
Archer, dat gaat ook door.
Ik zorg dat we hier haakjes hebben.
Nu, hier is het ding.
Idealiter zijn al deze tovenaars en boogschutters ook gebruikers, toch?
Dus we hebben gebruikers.
En deze gebruikers kunnen meerdere vormen hebben, ze kunnen tovenaars zijn, ze kunnen boogschutters zijn.
Het kunnen ogres zijn, alle personages in ons spel.
Maar laten we zeggen ze moeten allemaal eerst ingelogd zijn, hoe kunnen we ervoor zorgen dat al deze gebruikers of classis
ook toegang hebben om in te loggen?
Welnu, we kunnen overerving gebruiken en hoe doen we overerving vrij gemakkelijk, eigenlijk is alles wat we doen
tussen de haakjes de bovenliggende klasse doorgeven waarvan we willen erven.
Dus laten we zeggen dat ik hier yuzu doe.
Laten we nu hier op uitvoeren klikken.
Geen fouten.
Alles ziet er goed uit.
Trouwens, de groene lijn hier vertelt me dat inspringing geen veelvoud van vier is, omdat inspringing vier
zou moeten zijn in Python.
Dus we kunnen dit gewoon doen.
Maar ik hou het graag kleiner, zodat het gemakkelijker te lezen is.
OK, dus laten we hier een klasse instantiëren, ik ga een tovenaar maken en dan zeggen.
Wizard en voer die wizardklasse uit.
Nu, als ik hier print en ik doe laten we zeggen print wizard.
Als ik klik, ren dan weg.
Ik zie dat het wizard-object is gemaakt en wat moet ik doen als ik me niet aanmeld?
Ik zie dat ja, het is er eigenlijk als ik me aanmeld en op uitvoeren klik.
Hé, ik ben ingelogd.
Hoe gaaf is het dat ik deze functionaliteit heb geërfd van de gebruikersklasse.
En dit is echt heel krachtig, want nu kan ik mijn tovenaar uitbreiden, dus laten we
zeggen dat deze tovenaar een aangeboren karakter heeft.
Methode.
Die wordt uitgevoerd wanneer de wizard wordt gemaakt en heeft een.
Naam.
En macht die we krijgen.
En hier zullen we zelfnaam aan gelijke naam toewijzen en dan autodidactische macht aan gelijke macht.
En laten we ook nog een methode toevoegen.
Noem het aanval.
En deze aanvalsmethode drukt gewoon een F-tekenreeks af.
Dat zal zeggen.
Aanvallen met.
Kracht van.
Laten we zeggen autodidactische kracht.
En dan gaan we hetzelfde doen voor de Archer, dus ik ga deze code kopiëren.
Hier geplakt en de boogschutter heeft een naam.
En laten we zeggen in plaats van macht, zullen we zeggen dat het laten we zeggen.
Aantal Harrow's.
En aantal pijlen.
Zal het nieuwe attribuut zijn dat het krijgt en dan zal de aanval, nou ja, aanvallen met pijlen hebben.
En dan hebben we nog pijlen over.
Een pijl naar links geeft alleen het aantal fouten aan en we kunnen iets leuks doen waarbij de pijlen afnemen bij
elke aanval.
Oké, nu we dit hebben, laten we dit een beetje kleiner maken, zodat je het kunt zien.
Daar ga je.
Nu we dit hebben, laten we de eerste Schwyzer instantiëren.
Met.
Laten we zeggen Maalin met de kracht van 50.
En dan de boogschutter.
We worden geïnstantieerd.
Zoals Robin met, laten we zeggen, vijfhonderd helden of minder tot honderd uur.
Dus nu zullen de tovenaar en de boogschutter het hebben.
Wel, ze zullen het teken hebben.
Maar ze zullen ook de aanval hebben, maar uniek voor hun individu.
Klassen.
En ze zullen ook andere eigenschappen hebben.
Laten we eens kijken of ik Wizard Dot zou doen.
Dhr. Tovenaar.
Een stip.
En ik zal zeggen.
Aanval.
En laat me gewoon terugdraaien.
Mijn code-intelligentie.
We zullen zien dat we een paar fouten hebben.
Hier, wat staat er, ongedefinieerde naam zelf, en dat is omdat ik mezelf en de haakjes vergat.
Dus onthoud dat we altijd de eerste parameter zelf moeten geven.
Als we naar beneden scrollen en naar Wizard Dot gaan, zien we dat we naam, kracht en aanval hebben.
Als ik hier op aanval klik en ik ren weg.
We zien dat ik aanval met een kracht van 50 als ik boogschutter één punt aanval.
In dat geval zal ik aanvallen met pijlen, pijlen over honderd.
Maar beide hebben tegelijkertijd de inlogfunctie.
Hoe gaaf is dat dit de kracht van overerving is.
We houden onze code droog, oké, we abstraheren het deel van de code dat ze allebei
delen, maar veranderen dan dingen volgens wat iedereen nodig heeft.
Dus ik zou bijvoorbeeld andere methoden en eigenschappen op Wizzard kunnen hebben dan de Archer, maar
ook de gebruikersfunctionaliteit van een gedeelde gebruiker die ze hebben en op deze manier houdt haar code georganiseerd en schoon.
Laten we nu de zoom terugbrengen, zodat u het duidelijk kunt zien.
Dit idee van overerving is echt heel krachtig.
En de sleutel hier is dat we een paring-klasse en kinderklassen hebben.
Soms worden deze onderliggende klassen subklassen of afgeleide klassen genoemd omdat ze subklassen zijn van de gebruiker
of zijn afgeleid van de gebruikersklasse.
Laten we in de volgende video wat meer op dit onderwerp ingaan.