Tolkning 1
I C# er abstrakt og virtuelt forvirrende, begge knyttet til arv, og involverer bruk av overstyring. La oss diskutere forskjellene mellom de to:
1. Virtuell metode
virtuelt nøkkelord brukes for å endre metoder i basisklassen. Det finnes to situasjoner hvor virtuell brukes:
Scenario 1: En virtuell metode defineres i basisklassen, men den virtuelle metoden omskrives ikke i den avledede klassen. I kallet til den avledede klasseinstansen bruker den virtuelle metoden metoden definert av basisklassen.
Scenario 2: En virtuell metode defineres i basisklassen, og deretter skrives metoden om ved hjelp av overstyring i den avledede klassen. I kallet til den avledede klasseinstansen bruker den virtuelle metoden den avledede omskrivingsmetoden.
2. Abstrakt metode (abstrakt metode)
Det abstrakte nøkkelordet kan kun brukes i abstrakte klasser for å endre metoder, og det finnes ingen spesifikk implementering. Implementeringen av abstrakte metoder må implementeres ved å bruke overstyringsnøkkelordet i den avledede klassen.
Den viktigste forskjellen mellom et grensesnitt og en abstrakt klasse: en abstrakt klasse er en ufullstendig klasse, en abstraksjon av et objekt, mens et grensesnitt er en atferdsnorm.
3. Nøkkelord
Statisk: Når en metode erklæres som statisk, er metoden en statisk metode, og kompilatoren beholder implementasjonen av metoden ved kompileringstidspunktet. Det vil si at metoden tilhører en klasse, men ikke noe medlem, uavhengig av om en instans av klassen eksisterer eller ikke. Akkurat som inngangsfunksjonen Static void Main, kan den kalles direkte, fordi den er en statisk funksjon.
Virtua: Når en metode erklæres som virtuell, er det en virtuell metode inntil du bruker variabelen ClassName = ny ClassName(); Før man erklærer en instans av en klasse, eksisterer den ikke i det virkelige minnerommet. Dette nøkkelordet brukes svært ofte i klassearv for å gi polymorfismestøtte for klassemetoder.
overrride: indikerer en omskriving Denne klassen arver fra Shape-klassen
Virtuell, abstrakt er å fortelle andre klasser som vil arve fra ham at du kan overstyre denne metoden eller egenskapen min, ellers er det ikke tillatt.
Abstrakt: Abstrakt metodedeklarasjon er en metode som må overstyres av en avledet klasse, som brukes til å arves; Det kan betraktes som en imaginær metode uten realisering; Hvis en klasse inneholder en abstrakt metode, må klassen defineres som en abstrakt klasse, uavhengig av om den inneholder andre generelle metoder eller ikke; Abstrakte klasser kan ikke ha substanser.
a) Metoden for den virtuelle modifikasjonen må ha en metodeimplementering (selv om det bare er et par klammerparenteser), og metoden for den abstrakte modifikasjonen kan ikke ha en implementering.
b) virtuell kan omskrives av underklasser, abstrakt må omskrives av underklasser
c) Hvis en funksjon i en klasse modifiseres ved abstakt, må klassenavnet også endres med abstakt
d) Abstrakte modifiserte klasser kan ikke opprettes som instanser.
e) Hvis en metode i C# forberedes for å omskrive foreldreklassen i underklassen, må metoden modifiseres med virtual i foreldreklassen og overide i underklassen, slik at programmereren ved et uhell omskriver foreldremetoden til foreldreklassen i underklassen.
Merk: Klasser modifisert med abstrakt kan kun arves, ikke instansieres.
Tolkning 2
Både virtuell og abstrakt brukes for å endre foreldreklassen, slik at barneklassen kan omdefineres ved å overstyre definisjonen av foreldreklassen.
De har én ting til felles: hvis de brukes til å endre metoder, må offentlig legges til foran dem, ellers vil det oppstå kompileringsfeil: virtuelle metoder eller abstrakte metoder kan ikke være private. Tross alt gjør det å legge til virtuell eller abstrakt at underklassen kan omdefineres, og private medlemmer kan ikke nås av underklassen.
Men de er veldig forskjellige. (virtuell er "virtuell", abstrakt er "abstrakt").
(1) Metoden for virtuell modifikasjon må implementeres (selv om den bare legger til et par klammer), mens metoden med abstrakt modifikasjon ikke må implementeres. For eksempel, hvis metoden for virtuell modifikasjon ikke er implementert:
Feil: "Test1.fun1()" må erklære kroppen fordi den ikke er merket som abstrakt, ekstern eller delvis
For abstrakte modifikatorer, hvis implementert:
Feil: "Test2.fun2()" kan ikke erklære kroppen fordi den er merket som abstrakt
(2) virtuell kan omskrives av underklasser, mens abstrakt må omskrives av underklasser.
Det er ingen feil i kompilering; hvis metoden med virtuell modifikator skrives om, må overstyring legges til foran den (som forteller kompilatoren at du vil omskrive den virtuelle metoden), og det må finnes en implementasjon, ellers vil kompilasjonen være feil:
(3) Hvis et klassemedlem modifiseres av abstrakt, må abstrakt legges til før klassen, fordi kun abstrakte klasser kan ha abstrakte metoder.
(4) Instanser av abstrakte klasser kan ikke opprettes, de kan kun arves og kan ikke instansieres, for eksempel: BaseTest2 base2 = ny BaseTest2(); Det vil oppstå en kompileringsfeil: Abstrakt klasse eller grensesnitt kan ikke opprette en instans.
(5) I C#, hvis du vil omskrive en metode i en underklasse, må du legge til virtuel før foreldremetoden og overstyre før underklassemetoden, for å unngå at programmerere ved et uhell omskriver foreldremetoden i underklassen.
(6) Den abstrakte metoden må overskrives, og den virtuelle metoden må ha en implementasjon (selv om det er en metode definert i den abstrakte klassen).
Tolkning 3
Likheter:
1. De kan alle arves
2. Ingen av dem kan instansieres
3. Den kan inneholde metodedeklarasjoner
4. Avledede klasser må implementere urealiserte metoder
Skjelne:
1. Abstrakte baseklasser kan definere felt, attributter og metodeimplementeringer. Grensesnitt kan kun definere attributter, indeksere, hendelser og metodedeklarasjoner, og kan ikke inneholde felt.
2. En abstrakt klasse er en ufullstendig klasse som må videreforbedres, mens et grensesnitt er en atferdsnorm. Microsofts tilpassede grensesnitt kommer alltid med et kapabelt felt som beviser at de er uttrykk for «Jeg kan gjøre det...» ”
3. Grensesnitt kan implementeres flere ganger, og abstrakte klasser kan bare arves av én person
4. Abstrakte klasser er mer definerte mellom en serie nært beslektede klasser, mens de fleste grensesnittene er løst relaterte, men alle implementerer en bestemt funksjon
5. Abstrakte klasser er begreper abstrahert fra en rekke beslektede objekter, slik at de reflekterer tingenes indre fellesskap; Et grensesnitt er en funksjonell konvensjon definert for å tilfredsstille eksterne kall, så det reflekterer de ytre egenskapene til ting
6. Grensesnittet har i bunn og grunn ingen spesifikke arvelige egenskaper, det lover bare en metode som kan kalles
7. Grensesnittet kan brukes til å støtte tilbakeringinger, men arv har ikke denne funksjonen
8. De spesifikke metodene som implementeres av abstrakte klasser er virtuelle som standard, men grensesnittmetodene i klassen som implementerer grensesnittet er ikke-virtuelle som standard, selvfølgelig kan du også erklære dem virtuelle
9. Hvis den abstrakte klassen implementerer grensesnittet, kan metoden i grensesnittet mappes til den abstrakte klassen som en abstrakt metode uten å måtte implementere den, men metoden i grensesnittet kan implementeres i underklassen til den abstrakte klassen
Bruksregler:
1. Abstrakte klasser brukes hovedsakelig for nært beslektede objekter, mens grensesnitt best brukes for å gi generell funksjonalitet for irrelevante klasser
2. Hvis du vil designe en stor funksjonell enhet, bruk abstrakte klasser; Hvis du vil designe små, konsise funksjonsblokker, bruk grensesnitt.
3. Hvis flere versjoner av komponenten forventes å bli opprettet, lag en abstrakt klasse. Når et grensesnitt er opprettet, kan det ikke endres. Hvis en ny versjon av grensesnittet er nødvendig, må et helt nytt grensesnitt opprettes.
4. Hvis den opprettede funksjonen skal brukes mellom et bredt spekter av heterogene objekter, bruk grensesnittet; Hvis du vil tilby felles implementert funksjonalitet på tvers av alle implementasjoner av en komponent, bruk abstrakte klasser.
5. Analyser objektet, raffiner den interne fellesskapet for å danne en abstrakt klasse, som brukes til å uttrykke essensen av objektet, altså «hva». Grensesnitt prioriteres når eksterne kall eller funksjoner må utvides
6. En god grensesnittdefinisjon bør være spesifikk og funksjonell, ikke multifunksjonell, ellers vil det føre til grensesnittforurensning. Hvis en klasse bare implementerer én funksjon i grensesnittet, men må implementere andre metoder i grensesnittet, kalles det grensesnittforurensning
7. Prøv å unngå å bruke arv for å oppnå formasjonsfunksjonen, men bruk svart boks-multipleksing, altså objektkombinasjon. På grunn av økningen i antall arvenivåer er den mest direkte konsekvensen at når du kaller en klasse i denne taksonen, må du laste dem alle inn i stakken! Konsekvensene kan forestilles. (Kombinert med forståelse av stakkprinsipper). Samtidig kan interesserte venner legge merke til at Microsoft ofte bruker metoden objektkombinasjon når de bygger en klasse. For eksempel har Page-klassen i asp.net egenskaper som Server Request, men i virkeligheten er de alle objekter i en bestemt klasse. Å bruke dette objektet i Page-klassen for å kalle metodene og egenskapene til andre klasser er et svært grunnleggende designprinsipp
For eksempel:
Vindusformer kan designes med abstrakte klasser, og offentlige operasjoner og egenskaper kan plasseres i en abstrakt klasse, slik at formen og dialogboksen kan arve fra denne abstrakte klassen, og deretter utvides og forbedres etter eget behov.
Utskriftsoperasjonen kan tilbys som et grensesnitt til hvert skjema som trenger denne funksjonen, fordi innholdet i skjemaet er forskjellig, og de må implementere sin egen utskriftsfunksjon etter egne krav. Ved utskrift kalles det kun gjennom grensesnittet, uavhengig av hvilket skjema som skrives ut.
Fellesskap, individualitet og valg:
Noen bøker skriver at C# anbefaler å bruke grensesnitt i stedet for abstrakte baseklasser, og understreker de mange fordelene ved å bruke grensesnitt, noe jeg ikke tør være uenig i; fra listen ovenfor er det fortsatt mange forskjeller mellom de to, og eksistensen av denne forskjellen må avgjøre forskjellen i relevante scenarioer, for eksempel kan den abstrakte basisklassen gi standardimplementasjoner for noen metoder, for å unngå gjentatte implementeringer av dem i underklasser og forbedre gjenbrukbarheten av koden. Dette er fordelen med abstrakte klasser; Grensesnittet kan kun inneholde abstrakte metoder. Når det gjelder når man skal bruke abstrakte baseklasser og når man skal bruke grensesnitt, avhenger det av hvordan brukerne ser på forbindelsene mellom arvede klasser, om det er personlighetsforskjeller eller felles forbindelser mellom dem. La meg illustrere med et livseksempel.
Hvis du får tre objekter, nemlig mennesker, fisk og frosker, og du blir bedt om å designe en basiskategori for dem for å oppsummere forbindelsen mellom dem, vil det første du føler være at det er store forskjeller mellom dem, og det er vanskelig å abstrahere fellestrekkene. Her bør du vurdere å bruke grensesnitt i stedet for abstrakte baseklasser av tre grunner:
1. Individualitet er større enn fellesskap.
2. Personligheter med store forskjeller har noen av de samme atferdene.
3. Det er store forskjeller i realiseringsmetodene for samme atferd.
På dette tidspunktet får du tre objekter til, nemlig crucian carp, carp og goldfish, og lar deg fortsatt designe baseklasser for å oppsummere forbindelsen mellom dem, så det første du innser er at de alle tilhører fisk, og det andre er at måten de svømmer på kan være litt annerledes, så du bør bruke abstrakte baseklasser i stedet for grensesnitt, sammenlignet med eksempelet over er det tre grunner:
1. Fellesskap er større enn individualitet
2. Individer med samme fellestrekk må ha de samme egenskapene og atferdene
3. Det finnes visse forskjeller i implementeringsmetodene for samme oppførsel
Blant de flere grunnene til å bruke grensesnitt eller abstrakte baseklasser, er den tredje grunnen faktisk den samme, som beskriver konseptet polymorfi i objektorientert, det vil si at det implementeres ved å overskrive foreldreklassen og kalle den tilsvarende metoden under kjøring i henhold til objektreferansen som er passert. Den andre grunnen begynner å divergere, med grensesnitt som fremhever samme oppførsel mellom arvede objekter, mens abstrakte klasser også fremhever de samme egenskapene mellom arvede objekter. Det som virkelig skiller grensesnitt fra abstrakte basisklasser er følgende grunner:
Grensesnitt brukes når man søker funksjonell fellesskap mellom objekter med store forskjeller.
Abstrakte baseklasser brukes når funksjonelle forskjeller søkes mellom objekter med større fellesskap.
Ved å sammenligne det samme og forskjellige, kan vi bare si at grensesnitt og abstrakte klasser har sine egne styrker, men det finnes ingen fordeler. I faktisk programmeringspraksis må vi måle talentene våre ut fra den spesifikke situasjonen, men følgende erfaring og oppsamling kan gi deg litt inspirasjon, i tillegg til noe av min samling, kommer mange av dem fra klassikerne, jeg tror de kan tåle testen. Så når det gjelder regler og anledninger, lærer vi disse klassikerne, det viktigste er å anvende det vi har lært, selvfølgelig vil jeg vinne alles latter med ordene til en familie, vær så snill å fortsett.
Regler og anledninger:
1. Husk at et av de viktigste prinsippene for objektorientert tenkning er: grensesnittorientert programmering.
2. Med hjelp av grensesnitt og abstrakte klasser har mange ideer i de 23 designmønstrene blitt smart implementert, og jeg tror essensen rett og slett er at de er orientert mot abstrakt programmering.
3. Abstrakte klasser bør hovedsakelig brukes for nært beslektede objekter, mens grensesnitt best brukes for å gi generell funksjonalitet for irrelevante klasser.
4. Grensesnittet fokuserer på CAN-DO-relasjonstypen, mens den abstrakte klassen fokuserer på IS-A-relasjonen.
5. Oppførselen til flerdefinerte objekter i grensesnittet; abstrakte klasser multidefinerer objekters egenskaper;
6. Grensesnittdefinisjoner kan bruke offentlige, beskyttede, interne og private modifikatorer, men nesten alle grensesnitt er definert som offentlige, så det er ikke nødvendig å si mer.
7. «Grensesnittet forblir uendret» er en viktig faktor som bør vurderes. Derfor, når man legger til utvidelser fra grensesnitt, bør nye grensesnitt legges til, ikke eksisterende grensesnitt.
8. Prøv å designe grensesnittet som en funksjonell blokk med én funksjon, med .NET Framework som eksempel, IDisposable, IDisposable, IComparable, IEquatable, IEnumerable osv. inneholder alle bare én felles metode.
9. Den store bokstaven "I" foran grensesnittnavnet er en konvensjon, akkurat som feltnavnet starter med en understrek, vennligst følg disse prinsippene.
10. I grensesnittet går alle metoder som standard til offentlig.
11. Hvis versjonsproblemer forventes, kan du lage en "abstrakt klasse". For eksempel, hvis du lager en hund, en høne og en and, bør du vurdere å abstrahere dyr for å håndtere ting som kan oppstå i fremtiden. Å legge til nye medlemmer i grensesnittet tvinger alle avledede klasser til å modifiseres og kompileres på nytt, så versjonsproblemer implementeres best med abstrakte klasser.
12. Ikke-abstrakte klasser avledet fra abstrakte klasser må inkludere alle arvede abstrakte metoder og faktiske implementasjoner av abstrakte accessorer.
13. Det nye nøkkelordet kan ikke brukes for abstrakte klasser, og de kan heller ikke forsegles, fordi abstrakte klasser ikke kan instansieres.
14. Statiske eller virtuelle modifikatorer kan ikke brukes i abstrakte metodedeklarasjoner.
|
Publisert på 22.04.2019 14:41:09
|
|
|
