Interpretazione 1
In C#, Abstract e Virtual sono confusi, entrambi legati all'ereditarietà e coinvolgono l'uso dell'override. Parliamo delle differenze tra i due:
1. Metodo virtuale
la parola chiave virtuale viene usata per modificare i metodi nella classe base. Ci sono due situazioni in cui viene utilizzato il virtuale:
Scenario 1: Un metodo virtuale è definito nella classe base, ma il metodo virtuale non viene riscritto nella classe derivata. Nella chiamata all'istanza di classe derivata, il metodo virtuale utilizza il metodo definito dalla classe base.
Scenario 2: Un metodo virtuale viene definito nella classe base e poi il metodo viene riscritto usando l'override nella classe derivata. Nella chiamata all'istanza di classe derivata, il metodo virtuale utilizza il metodo di riscrittura derivata.
2. Metodo astratto (metodo astratto)
La parola chiave abstract può essere usata solo nelle classi astratte per modificare i metodi, e non esiste un'implementazione specifica. L'implementazione dei metodi astratti deve essere realizzata utilizzando la parola chiave di sovrascrittura nella classe derivata.
La differenza più essenziale tra un'interfaccia e una classe astratta: una classe astratta è una classe incompleta, un'astrazione di un oggetto, mentre un'interfaccia è una norma comportamentale.
3. Parole chiave
Statico: Quando un metodo viene dichiarato come Statico, il metodo è un metodo statico e il compilatore mantiene l'implementazione del metodo al momento della compilazione. Cioè, il metodo appartiene a una classe, ma non a nessun membro, indipendentemente dal fatto che un'istanza della classe esista o meno. Proprio come la funzione di ingresso Static void Main, poiché è una funzione statica, può essere chiamata direttamente.
Virtua: Quando un metodo viene dichiarato come Virtuale, è un metodo virtuale finché non si usa la variabile ClassName = nuovo ClassName(); Prima di dichiarare un'istanza di una classe, essa non esiste nello spazio di memoria reale. Questa parola chiave è molto comunemente usata nell'ereditarietà di classi per fornire supporto al polimorfismo ai metodi di classe.
override: indica una riscrittura Questa classe eredita dalla classe Shape
Virtuale, astratto serve a dire alle altre classi che vogliono ereditare da lui che puoi sovrascrivere questo metodo o proprietà mia, altrimenti non è permesso.
Abstract: La dichiarazione del metodo abstract è un metodo che deve essere sovrascritto da una classe derivata, che viene usata per essere ereditata; Può essere considerato un metodo immaginario senza realizzazione; Se una classe contiene un metodo astratto, allora la classe deve essere definita come una classe astratta, indipendentemente dal fatto che contenga o meno altri metodi generali; Le classi astratte non possono avere sostanze.
a) Il metodo della modifica virtuale deve avere un'implementazione del metodo (anche se si tratta solo di una coppia di parentesi), e il metodo della modifica astratta non può avere un'implementazione.
b) il virtuale può essere riscritto dalle sottoclassi, l'abstract deve essere riscritto dalle sottoclassi
c) Se una funzione in una classe viene modificata da abstact, anche il nome della classe deve essere modificato con abstact
d) Le classi astratte modificate non possono essere create istanze.
e) Se un metodo in C# è pronto a riscrivere la classe genitore nella sottoclasse, il metodo deve essere modificato con virtual nella classe genitore e sovrastato nella sottoclasse, evitando che il programmatore riscrive accidentalmente il metodo padre della classe genitore nella sottoclasse.
Nota: Le classi modificate con abstract possono solo essere ereditate, non istanziate.
Interpretazione 2
Sia virtuale che astratto vengono utilizzati per modificare la classe genitore, permettendo di ridefinire la classe figlia sovrascrivendo la definizione della classe genitore.
Hanno una cosa in comune: se vengono usati per modificare metodi, il pubblico deve essere aggiunto davanti a loro, altrimenti ci saranno errori di compilazione: i metodi virtuali o i metodi astratti non possono essere privati. Dopotutto, aggiungere virtuale o astratto permette di ridefinire la sottoclasse, e i membri privati non possono essere accessibili dalla sottoclasse.
Ma sono molto diversi. (virtuale è "virtuale", astratti sono "astratti").
(1) Il metodo di modifica virtuale deve essere implementato (anche se aggiunge solo una coppia di parentesi), mentre il metodo di modifica astratta non deve essere implementato. Ad esempio, se il metodo di modifica virtuale non è implementato:
Errore: "Test1.fun1()" deve dichiarare il corpo perché non è contrassegnato come astratto, esterno o parziale
Per i modificatori astratti, se implementati:
Errore: "Test2.fun2()" non può dichiarare il corpo perché è marcato come astratto
(2) il virtuale può essere riscritto dalle sottoclassi, mentre l'abstract deve essere riscritto dalle sottoclassi.
Non c'è errore nella compilazione, se il metodo del modificatore virtuale viene riscritto, davanti deve essere aggiunta l'override (che indica al compilatore che si vuole riscrivere il metodo virtuale), e deve esserci un'implementazione, altrimenti la compilazione sarà sbagliata:
(3) Se un membro di classe viene modificato da abstract, abstract deve essere aggiunto prima della classe, perché solo le classi astratte possono avere metodi astratti.
(4) Le istanze di classi astratte non possono essere create, possono solo essere ereditate e non possono essere istanziate, ad esempio: BaseTest2 base2 = nuovo BaseTest2(); Ci sarà un errore di compilazione: la classe astratta o l'interfaccia non possono creare un'istanza.
(5) In C#, se si vuole riscrivere un metodo in una sottoclasse, è necessario aggiungere virtuale prima del metodo genitore e sovrascrivere prima del metodo della sottoclasse, per evitare che i programmatori riscriveno accidentalmente il metodo padre nella sottoclasse.
(6) Il metodo astratto deve essere sovrascritto, e il metodo virtuale deve avere un'implementazione (anche se è un metodo definito nella classe astratta).
Interpretazione 3
Somiglianze:
1. Possono essere tutti ereditati
2. Nessuno di essi può essere istanziato
3. Può contenere dichiarazioni di metodo
4. Le classi derivate devono implementare metodi non realizzati
Distinguere:
1. Le classi base astratte possono definire campi, attributi e implementazioni di metodi. Le interfacce possono definire solo attributi, indicizzatori, eventi e dichiarazioni di metodi, e non possono contenere campi.
2. Una classe astratta è una classe incompleta che necessita di ulteriori affinazioni, mentre un'interfaccia è una norma comportamentale. Le interfacce personalizzate di Microsoft sono sempre dotate di un campo valido per dimostrare di essere espressioni del "Posso farcela..." ”
3. Le interfacce possono essere implementate più volte, e le classi astratte possono essere ereditate solo da una singola persona
4. Le classi astratte sono più definite tra una serie di classi strettamente correlate, mentre la maggior parte delle interfacce è vagamente correlata ma tutte implementano una certa funzione
5. Le classi astratte sono concetti astratti da una serie di oggetti correlati, quindi riflettono la comunanza interna delle cose; Un'interfaccia è una convenzione funzionale definita per soddisfare chiamate esterne, quindi riflette le caratteristiche esterne delle cose
6. L'interfaccia fondamentalmente non ha caratteristiche specifiche di ereditarietà, promette solo un metodo che può essere chiamato
7. L'interfaccia può essere utilizzata per supportare callback, ma l'ereditarietà non possiede questa funzione
8. I metodi specifici implementati dalle classi astratte sono virtuali di default, ma i metodi di interfaccia nella classe che implementano l'interfaccia sono non virtuali di default; ovviamente, puoi anche dichiararli virtuali
9. Se la classe astratta implementa l'interfaccia, il metodo nell'interfaccia può essere mappato alla classe astratta come metodo astratto senza doverlo implementare, ma il metodo nell'interfaccia può essere implementato nella sottoclasse della classe astratta
Regole d'uso:
1. Le classi astratte sono principalmente usate per oggetti strettamente correlati, mentre le interfacce sono meglio utilizzate per fornire funzionalità generali per classi irrilevanti
2. Se vuoi progettare una grande unità funzionale, usa classi astratte; Se vuoi progettare blocchi funzionali piccoli e concisi, usa interfacce.
3. Se si prevede la creazione di più versioni del componente, si crea una classe astratta. Una volta creata un'interfaccia, non può essere modificata. Se è richiesta una nuova versione dell'interfaccia, deve essere creata una interfaccia completamente nuova.
4. Se la funzione creata sarà usata tra un'ampia gamma di oggetti eterogenei, si usa l'interfaccia; Se vuoi fornire funzionalità implementate comuni in tutte le implementazioni di un componente, usa classi astratte.
5. Analizzare l'oggetto, affinare la comunanza interna per formare una classe astratta, che viene usata per esprimere l'essenza dell'oggetto, cioè "cosa". Le interfacce sono prioritarie quando è necessario espandere chiamate o funzioni esterne
6. Una buona definizione di interfaccia dovrebbe essere specifica e funzionale, non multifunzionale, altrimenti causerà inquinamento dell'interfaccia. Se una classe implementa solo una funzione dell'interfaccia, ma deve implementare altri metodi nell'interfaccia, si chiama inquinamento dell'interfaccia
7. Cerca di evitare di usare l'ereditarietà per ottenere la funzione di formazione, ma usa il multiplexing a scatola nera, cioè la combinazione di oggetti. A causa dell'aumento del numero di livelli di eredità, la conseguenza più diretta è che quando chiami una classe in questo taxon, devi caricarle tutte nella pila! Le conseguenze sono immaginabili. (Combinato con la comprensione del principio dello stack). Allo stesso tempo, gli amici interessati possono notare che Microsoft spesso utilizza il metodo della combinazione di oggetti quando costruisce una classe. Ad esempio, in asp.net, la classe Page ha proprietà come Server Request, ma in realtà sono tutte oggetti di una certa classe. Utilizzare questo oggetto della classe Page per chiamare i metodi e le proprietà di altre classi è un principio di progettazione molto basilare
Per esempio:
I form delle finestre possono essere progettati con classi astratte, e le operazioni e le proprietà pubbliche possono essere inserite in una classe astratta, così che la forma e la finestra di dialogo possano ereditare da questa classe astratta, per poi espandersi e migliorare secondo le proprie esigenze.
L'operazione di stampa può essere fornita come interfaccia per ogni modulo che necessita di questa funzione, poiché il contenuto del modulo è diverso e devono implementare la propria funzione di stampa secondo le proprie esigenze. Durante la stampa, viene chiamata solo tramite l'interfaccia, indipendentemente dal modulo stampato.
Comunità, individualità e scelta:
Alcuni libri scrivono che C# raccomanda di usare interfacce invece delle classi base astratte, e sottolineano i numerosi vantaggi dell'uso delle interfacce, con cui non oso dissentire, dall'elenco sopra ci sono ancora molte differenze tra le due, e l'esistenza di questa differenza deve determinare la differenza negli scenari applicabili; ad esempio, nella classe base astratta può fornire implementazioni predefinite per alcuni metodi, per evitare implementazioni ripetute nelle sottoclassi e migliorare la riutilizzabilità del codice. Questo è il vantaggio delle classi astratte; L'interfaccia può contenere solo metodi astratti. Per quanto riguarda quando usare le classi base astratte e quando usare le interfacce, dipende da come gli utenti vedono le connessioni tra le classi ereditate, se si tratti di differenze di personalità o di connessioni comuni tra di esse. Lasciate che vi illustri con un esempio di vita.
Se ti vengono dati tre oggetti, ovvero persone, pesci e rane, e ti viene chiesto di progettare una categoria base per loro per riassumere la connessione tra loro, allora la prima cosa che sentirai è che ci sono grandi differenze tra di essi, ed è difficile astrarre le sfumature in comune. Qui dovresti considerare l'uso di interfacce invece delle classi base astratte per tre motivi:
1. L'individualità è più grande della comunità.
2. Le personalità con grandi differenze hanno alcuni degli stessi comportamenti.
3. Ci sono grandi differenze nei metodi di realizzazione dello stesso comportamento.
A questo punto, ti vengono dati altri tre oggetti, ovvero carpa crocia, carpa e pesce rosso, e ti permetti comunque di progettare classi base per riassumere la connessione tra loro; poi la prima cosa che capisci è che appartengono tutti ai pesci, e la seconda è che il modo in cui nuotano può essere leggermente diverso, quindi dovresti usare classi base astratte invece di interfacce; rispetto all'esempio sopra, ci sono tre motivi:
1. La comunanza è superiore all'individualità
2. Gli individui con la stessa comunanza devono avere gli stessi attributi e comportamenti
3. Ci sono alcune differenze nei metodi di implementazione dello stesso comportamento
Tra le varie ragioni per l'uso di interfacce o classi base astratte, la terza ragione è in realtà la stessa, che descrive il concetto di polimorfismo nell'orientamento agli oggetti, cioè viene implementato sovrascrivendo la classe genitore e chiamando il metodo corrispondente a runtime in base al riferimento all'oggetto passato. La seconda ragione inizia a divergere, con interfacce che enfatizzano lo stesso comportamento tra oggetti ereditati, mentre le classi astratte enfatizzano anch'esse le stesse proprietà tra oggetti ereditati. Ciò che distingue davvero le interfacce dalle classi base astratte sono le seguenti ragioni:
Le interfacce vengono utilizzate quando si cerca una comunanza funzionale tra oggetti con grandi differenze.
Le classi base astratte sono utilizzate quando si cercano differenze funzionali tra oggetti con maggiore comunità.
Confrontando le stesse e le diverse, possiamo solo dire che le interfacce e le classi astratte hanno i loro punti di forza, ma non ci sono vantaggi. Nella pratica di programmazione reale, dobbiamo misurare i nostri talenti in base alla situazione specifica, ma l'esperienza e l'accumulo che segueno possono darti ispirazione, oltre ad alcune delle mie accumulazioni, molte di esse provengono dai classici, credo che possano resistere alla prova. Quindi, nelle regole e nelle occasioni, impariamo questi classici, la cosa più importante è applicare ciò che abbiamo imparato, ovviamente, farò ridere tutti con le parole di una famiglia, per favore continuate.
Regole e occasioni:
1. Ricorda che uno dei principi più importanti del pensiero orientato agli oggetti è: la programmazione orientata all'interfaccia.
2. Con l'aiuto di interfacce e classi astratte, molte idee nei 23 pattern di design sono state implementate in modo intelligente, e penso che la loro essenza sia semplicemente orientata alla programmazione astratta.
3. Le classi astratte dovrebbero essere usate principalmente per oggetti strettamente correlati, mentre le interfacce sono meglio utilizzate per fornire funzionalità generali per classi irrilevanti.
4. L'interfaccia si concentra sul tipo di relazione CAN-DO, mentre la classe astratta si concentra sulla relazione IS-A.
5. Il comportamento degli oggetti multidefiniti nell'interfaccia; le classi astratte definiscono più proprietà degli oggetti;
6. Le definizioni di interfaccia possono utilizzare modificatori pubblici, protetti, interni e privati, ma quasi tutte le interfacce sono definite come pubbliche, quindi non è necessario aggiungere altro.
7. "L'interfaccia rimane invariata" è un fattore importante da considerare. Pertanto, quando si aggiungono estensioni dalle interfacce, dovrebbero essere aggiunte nuove interfacce, non interfacce esistenti.
8. Cerca di progettare l'interfaccia in un blocco funzionale con una sola funzione, prendendo come esempio .NET Framework: IDisposable, IDisposable, IComparable, IEquatable, IEnumerable, ecc. contengono tutti un solo metodo comune.
9. La lettera maiuscola "I" davanti al nome dell'interfaccia è una convenzione, proprio come il nome del campo inizia con sottolinea, si prega di rispettare questi principi.
10. Nell'interfaccia, tutti i metodi sono predefiniti su pubblico.
11. Se sono previsti problemi di versione, puoi creare una "classe astratta". Ad esempio, se crei un cane, una gallina e un'anatra, dovresti considerare di astratere gli animali per affrontare le situazioni che potrebbero sorgere in futuro. Aggiungere nuovi membri all'interfaccia costringe tutte le classi derivate a essere modificate e ricompilate, quindi i problemi di versioning sono meglio implementati con classi astratte.
12. Le classi non astratte derivate da classi astratte devono includere tutti i metodi astratti ereditati e le implementazioni effettive degli accessori astratti.
13. La nuova parola chiave non può essere usata per classi astratte, né possono essere sigillate, perché le classi astratte non possono essere istanziate.
14. Modificatori statici o virtuali non possono essere utilizzati nelle dichiarazioni di metodi astratti.
|
Pubblicato su 22/04/2019 14:41:09
|
|
|
