Perché ho bisogno di interfaccia?

Question

Eventuali duplicati:
Interfaces: Why can't I seem to grasp them?
Why would I want to use Interfaces?

Penso che questa domanda viene ripetuta 1000 volte e mi dispiace per chiedere di nuovo. Cerco davvero una semplice risposta, perché ho bisogno di un'interfaccia esplicita, o se per favore spieghi qualcosa che non posso realizzare senza Interface.

Se è un'eredità multipla, vorrei chiedervi di fornirmi un semplice esempio attraverso il quale posso capire perché ho bisogno di un'interfaccia.

--Thx in anticipo.

Nota: Sto chiedendo a questa domanda in un contesto di NET (C#) lingua

Edit1: Per ora ogni volta che provo a imparare l'interfaccia mia mente mi dice -> "compagno che si sta per delineare il corpo di qualcuno in un foglio bianco "Ma hai bisogno di un altro foglio bianco dove devi disegnare nuovamente il contorno, disegnare tutte le parti del corpo per riempire i colori per ottenere il quadro reale." Quindi perché sto sprecando il primo foglio bianco solo per ottenere il profilo

Answer 1

Il modo più semplice per comprendere le interfacce è che consentono a oggetti diversi di esporre la funzionalità COMMON. Ciò consente al programmatore di scrivere molto più semplice, codice più corto che programma su un'interfaccia, quindi finché gli oggetti implementano quell'interfaccia funzionerà.

Provider

Database:

Ci sono molti fornitori di database diversi, MySQL, MSSQL, Oracle, ecc, tuttavia tutti gli oggetti di database in grado di fare le stesse cose in modo troverete molte interfacce per gli oggetti di database. Se un oggetto implementa IDBConnection, espone i metodi Open() e Close(). Quindi, se voglio che il mio programma sia indipendente dal provider di database, programma l'interfaccia e non i provider specifici.

IDbConnection connection = GetDatabaseConnectionFromConfig() 
connection.Open() 
// do stuff 
connection.Close() 

V., per la programmazione di un'interfaccia (IDbConnection) Ora posso scambiare qualsiasi provider di dati nel mio config ma il mio codice rimane esattamente lo stesso. Questa flessibilità può essere estremamente utile e facile da mantenere. Il lato negativo di questo è che posso eseguire solo operazioni di database "generiche" e che non posso sfruttare appieno la forza offerta da ciascun fornitore in modo tale che con tutto ciò che si sta programmando si ha un compromesso e si deve determinare quale scenario sarà più vantaggioso.

Collezioni:

Se si nota quasi tutte le collezioni implementare questa interfaccia IEnumerable chiamato. IEnumerable restituisce un IEnumerator che ha MoveNext(), Current e Reset(). Ciò consente a C# di spostarsi facilmente nella tua collezione. La ragione per cui può farlo è che espone l'interfaccia IEnumerable che CONOSCE che l'oggetto espone i metodi necessari per attraversarlo. Questo fa due cose. 1) foreach loops ora saprà come enumerare la raccolta e 2) ora puoi applicare potenti espression LINQ alla tua collezione. Ancora una volta il motivo per cui le interfacce sono così utili qui è perché tutte le collezioni hanno qualcosa in COMMON, possono essere spostate. Ogni collezione può essere spostata in un modo diverso (elenco collegato vs array) ma questa è la bellezza delle interfacce è che l'implementazione è nascosta e irrilevante per il consumatore dell'interfaccia. MoveNext() ti dà il prossimo oggetto della collezione, non importa come lo fa. Abbastanza carino, eh?

polimorfismo

Quando si progetta le proprie interfacce basta porsi una domanda. Cosa hanno in comune queste cose? Una volta trovate tutte le cose che condividono gli oggetti, si astraggono tali proprietà/metodi in un'interfaccia in modo che ogni oggetto possa ereditarsene. Quindi puoi programmare contro diversi oggetti usando un'unica interfaccia.

E ovviamente devo dare il mio esempio polimorfico C++ preferito, l'esempio degli animali. Tutti gli animali condividono determinate caratteristiche. Diciamo che possono muoversi, parlare e hanno tutti un nome. Da quando ho appena identificato ciò che tutti i miei animali hanno in comune e posso astrarre quelle qualità nell'interfaccia IAnimal. Quindi creo un oggetto Bear, un oggetto Owl e un oggetto Snake che implementano questa interfaccia.Il motivo per cui è possibile memorizzare diversi oggetti insieme che implementano la stessa interfaccia è perché le interfacce rappresentano una sostituzione di IS-A. Un orso è un animale, un gufo è un animale, così da quando posso raccoglierli tutti come animali.

var animals = new IAnimal[] = {new Bear(), new Owl(), new Snake()} // here I can collect different objects in a single collection because they inherit from the same interface 

foreach (IAnimal animal in animals) 
{ 
    Console.WriteLine(animal.Name) 
    animal.Speak() // a bear growls, a owl hoots, and a snake hisses 
    animal.Move() // bear runs, owl flys, snake slithers 
} 

Si può vedere che, anche se questi animali svolgono ogni azione in un modo diverso, posso programmare contro di loro tutti in un modello unificato e questo è solo uno dei molti vantaggi di interfacce.

Quindi, ancora una volta, la cosa più importante con le interfacce è ciò che gli oggetti hanno in comune in modo che sia possibile programmare contro DIVERSI oggetti nel modo SAME. Risparmia tempo, crea applicazioni più flessibili, nasconde complessità/implementazione, modella oggetti/situazioni del mondo reale, tra molti altri vantaggi.

Spero che questo aiuti.

Answer 2

Un'interfaccia è un Contratto per ciò che la classe può fare, ciò significa che una singola classe può soddisfare più contratti S.

Una classe astratta è un modello per come deve comportarsi una classe, è possibile compilare solo un modello per classe.

Una classe estesa accetta un oggetto esistente e aggiunge/cambia funzionalità, è possibile estendere solo una classe genitore per classe.

Si utilizzerà un contratto (interfaccia) se si desidera descrivere come deve comportarsi qualcosa senza definire l'implementazione specifica. Questo contratto può essere soddisfatto da qualsiasi altra classe che implementa i metodi/proprietà che sono definiti.

Si utilizzerà una classe astratta se si desidera specificare parte della funzionalità in primo piano e quindi aggiungerla.

EDIT: Considerate questo:

Si dispone di un'applicazione che ha bisogno di memorizzare alcuni dati Say EntityA ma si può avere molteplici modi in cui è possibile memorizzare i dati (ad esempio, xml, database SQL, CSV ect). È possibile creare una classe per ciascuno di questi diversi metodi per archiviare EntityA. ma quando volevi cambiare metodo avresti bisogno di specificare esplicitamente il tipo che vuoi proprio lì.

cioè

public class DoStuffWithEntityA{ 
    public void DoStuffAndStoreAsXml(EntityA entity){ /*Logic*/} 
    public void DoStuffAndStoreAsCsv(EntityA entity){ /*Logic*/} 
    public void DoStuffAndStoreInDatabase(EntityA entity){ /*Logic*/} 
} 

prehaps un modo migliore è quello di utilizzare un'interfaccia che descrive in generale cosa qualcosa che memorizza EntityA sarà simile.

esempio

public interface IStoreEntityA{ 
    void Store(EnitityA entity); 
} 

allora si può solo dire che si desidera qualcosa che memorizza EntityA nel codice

public class DoStuffWithEntityA{ 
    private IStoreEntityA _entityAStorer; 
    public DoStuffWithEntityA(IStoreEntityA howIStoreEntityA){ _entityAStorer = howIStoreEntityA;} 
    public void DoStuff(EntityA entity) 
    { 
     //Do Stuff 
     _entityAStorer.Store(entity); 
    } 
} 

Questo significa che l'isnt logica strettamente accoppiato al modo in cui si memorizzano EntityA