‫In deze les leert u het cruciale verschil tussen activaklassen en interfaces bij het ontwerpen van
‫applicaties.
‫Het is essentieel om te weten wanneer je een abstracte klasse moet gebruiken en wanneer je een interface moet gebruiken en wanneer geen van
‫beide.
‫Abstracte klassen en interfaces lijken in sommige opzichten op elkaar, maar er zijn belangrijke verschillen die bepalen
‫wat de beste keuze is voor wat u probeert te bereiken.
‫Het verschil tussen een abstracte klasse en een interface begrijpen is erg belangrijk, zodat
‫we losjes gekoppelde en uitbreidbare applicaties kunnen ontwerpen, zodat we applicaties gemakkelijk kunnen aanpassen en wijzigen
‫zonder alles kapot te maken.
‫In deze video bespreken we die verschillen en hoe je kunt beslissen wanneer je welke moet gebruiken.
‫Maar voordat we dat doen, laten we eerst ons geheugen opfrissen over abstracte klassen en interfaces.
‫Dus eerst, abstracte klassen en abstracte klasse is een onvolledige klasse of een klasse die niet kan worden geïnstantieerd, wat betekent dat we
‫er geen objecten van kunnen maken.
‫Het doel van een abstracte klasse is om een blauwdruk te bieden voor afgeleide klassen en om enkele regels in te
‫stellen, zoals wat de afgeleide klassen moeten implementeren.
‫Maar waarom zouden we een klasse nodig hebben om te worden gemarkeerd als een abstracte klasse om mee te beginnen?
‫Wat is er mis met reguliere lessen?
‫Stel je voor dat we een klassemotor en een klasseauto hebben en dat ze een aantal functies delen om coderedundantie
‫te verminderen.
‫We maken een basisklasse met de naam Vehicle om te voorkomen dat er instanties van het type voertuig worden gemaakt en om elke methode af
‫te dwingen om hun versie van de voertuigmethoden te implementeren.
‫We moeten het markeren als een abstracte klasse.
‫We kunnen voordeel halen uit abstracte klassen om componenten te ontwerpen en een bepaald niveau van gemeenschappelijke functionaliteit te specificeren
‫die door de juiste klassen moet worden geïmplementeerd.
‫Dus laten we dit voertuig abstract maken en dit komt goed.
‫Laten we nu nog eens naar interfaces kijken.
‫Een interface is dus een contract en kan alleen methodedeclaraties bevatten.
‫Het kan geen methodedefinities bevatten.
‫Ze definiëren een vaardigheid die een klasse heeft.
‫Stel dat we drie klassen hebben.
‫Dus we hebben de klasse, fiets, motor en auto.
‫En dan willen we er zeker van zijn dat al deze klassen erven van dit klassevoertuig.
‫En als je bijvoorbeeld zelfrijdende functionaliteit aan onze auto wilt toevoegen, en wij andere klassen willen creëren,
‫die bijvoorbeeld een vliegtuig kunnen creëren, heeft het geen zin om de zelfrijdende functionaliteit toe te voegen aan
‫onze auto. het voertuig van de beste klasse, omdat niet al onze subklassen deze functie
‫hebben.
‫Het zou handiger zijn om het toe te voegen in de vorm van een interface genaamd AI self-driving.
‫Dan kunnen deze klassen die deze interface implementeren de logica bieden om dit te bereiken.
‫Laten we het nu hebben over overeenkomsten tussen interfaces en abstracte klassen, zowel interfaces als abstracte
‫klassen kunnen worden geïnstantieerd.
‫Het betekent dat we er geen objecten van kunnen maken.
‫Maar ze ondersteunen allebei polymorfisme, wat betekent dat we een object van het type cad kunnen opslaan in een variabele van het
‫type, abstract class animal.
‫Hetzelfde geldt voor interfaces waar we elke verzameling zoals een lijst of een stapel kunnen opslaan in een variabele van
‫Type II enumerable.
‫Laten we nu eens kijken naar de belangrijkste verschillen.
‫Een abstracte klasse is ontworpen om te worden geërfd door subklassen die de methoden ervan implementeren of overschrijven.
‫Met andere woorden, abstracte klassen zijn gedeeltelijk of helemaal niet geïmplementeerd.
‫Aan de andere kant zijn interfaces helemaal niet geïmplementeerd.
‫Dan kan een abstracte klasse geen tegengestelde constructor hebben.
‫Abstracte klassen kunnen constructors en velden hebben, evenals methodedefinities, en de implementatie is de
‫verantwoordelijkheid van de klasse die de interface heeft geïmplementeerd.
‫Aan de andere kant kan een abstracte klasse methode, definities en velden bevatten en interfaces hebben geen constructors,
‫zoals we al zeiden, ze kunnen ook geen velden hebben.
‫Dus nu kunnen klassen veel interfaces implementeren, wat een manier is om een soort van multi-overerving te bereiken.
‫Omdat teashop een enkele overervingstaal is en dat standaard niet toestaat.
‫Toch kan een klasse slechts één klasse erven.
‫Dus als een klasse een interface heeft geïmplementeerd, moet deze al zijn leden implementeren, zoals eigenschappen,
‫methoden, enzovoort, aan de andere kant, wanneer een klasse een abstracte klasse uitbreidt,
‫moet deze zijn abstracte leden alleen implementeren zodat ze het niet-geïmplementeerde deel kennen van de abstracte klasse.
‫Laten we hier naar een analogie kijken.
‫Stel je voor dat je een scherpe instructeur bent, waar de instructeur niets kan bereiken tenzij hij een expert is in een
‫onderwerp of zij een expert is in een onderwerp, omdat we geen voorbeelden van abstracte lessen kunnen hebben.
‫Dus een instructeur zou een expert in een onderwerp moeten worden om het te onderwijzen.
‫Dus de instructeur werd een C sharp-expert en nu kan hij of zij deze sharp aanleren op een gegeven moment
‫moest de C sharp-instructeur video's bewerken, hoewel niet alle instructeurs hetzelfde hoeven te doen.
‫Dus hebben we de interface I video-editor geïmplementeerd om dit te laten werken.
‫Dus niet alle instructeurs hoeven te kunnen bewerken, maar degenen die deze video-editor implementeren, moeten
‫dit wel doen.
‫Oke.
‫Ten eerste, als u bij het ontwerpen van de C-shopklasse overerving boven een interface kiest, zullen bibliotheken een extra
‫klasse gebruiken.
‫Als je functionaliteit hebt die je wilt, zijn het subklassen die je moet hebben.
‫Als u bijvoorbeeld een set functies heeft, wilt u dat subklassen deze in een abstracte klasse hebben
‫geplaatst.
‫De abstracte klasse wordt gebruikt wanneer de afgeleide klasse de kerneigenschappen en het gedrag van de abstracte klasse
‫deelt, het soort gedrag dat de gebruikersinterface van de klasse definieert.
‫Als u een algemeen contract wilt over een gedrag of functionaliteit, zijn interfaces meestal los in vergelijking
‫met abstracte klassen.
‫U zou geen interfaces willen gebruiken in een situatie waarin u constant dezelfde code schrijft
‫voor alle interfacemethoden.
‫Gebruikte een abstracte klasse en definieer elke methode één keer.
‫Een korte samenvatting dus.
‫Als we het hebben over abstracte klassen, definiëren we de kenmerken van een objecttype en specificeren we wat een
‫object is.
‫Als we het hebben over een interface en mogelijkheden definiëren die we beloofd hebben te bieden, hebben we het
‫over het opstellen van een contract over wat het object kan doen.
‫Dus wat het object is, is abstracte klasse, wat het object kan doen.
‫En interface.
‫Oké, dus ik hoop dat je genoten hebt van de samenvatting en dit overzicht van
‫de twee verschillende soorten benaderingen.
‫En laten we nu doorgaan en die concepten en verschillende voorbeelden gebruiken in de volgende colleges en in de rest
‫van de cursus.