Oppure

Loading
03/07/13 18:09
tuttodiMC
Come da oggetto: che me ne faccio delle innterfacce? Qual é la loro vera utilità?
aaa
03/07/13 18:19
GN
aaa
05/07/13 19:20
Dedalux
Le interfacce servono principalmente per slegare l'entità dall'implementazione, ossia accedere ai membri definiti nell'interfaccia senza sapere che tipo di classe si sta utilizzando.
Tra i vari vantaggi, questo permette di avere molto flessibilità nel refactoring. Permette infatti di cambiare facilmente l'implementazione senza dover andare a cambiare tutti i 1000 pezzi di codice dove è scritto il nome della classe. (vedi Dependency Injection)

Es.
interfaccia IDataService
implementazioni XMLDataService, JSONDataService, DBFDataService, ecc....

l'intefaccia mettiamo che abbia due metodi LoadData() e StoreData()

sempre che in tutte le implementazioni il valore di ritorno sia IEnumerable<Person>

è possibile lavorare sempre sull'interfaccia, e fregarsene di che database c'è sotto, cosa di cui si occuperà solo chi fornisce l'implementazione giusta all'inizio

senza usare l'interfaccia ci sarebbe bisogno in ogni momento in cui ci fosse bisogno di accedere ai dati, verificare di che tipo di dati si tratta, e scegliere l'implementazione, oltre al fatto che se volessi un giorno cambiare da XML a JSON, dovrei cambiare 10-20-30 volte tutti i punti in cui c'è il nome specifico dell'implementazione, mentre con l'interfaccia solo una volta

se non sono stato chiaro mi scuso ma sono di fretta, domanda pure
aaa
08/07/13 19:43
tuttodiMC
Dedalux apprezzo la professionalità ma non ci ho capito un tubo (ho 15 anni e sono appena entrato nell'informatica). Comunque grazie alla guida di Visual Basic del sito indicatami da GN ho capito la loro utilità. Anche se mi chiedo ancora: ma se deve starci scritto solo il nome dei campi e dei metodi, che senso ha se dopo vado a fare l'implementazione in una classe?
Ultima modifica effettuata da tuttodiMC 08/07/13 19:44
aaa
10/07/13 18:12
Dedalux
L'implementazione la fai proprio sulla base dell'interfaccia.
L'interfaccia dice: la classe che mi implementa deve avere questi membri, con questi nomi, e di questi tipi. Delle loro azioni non sono responsabile io.

Ho provato a rispondere, ma sinceramente non ho capito il tuo dubbio.
Ti domandi che senso abbia l'esistenza dell'interfaccia o che altro?
Se riesci a porre la domanda in modo più esteso provo a risponderti meglio. :k:
Ultima modifica effettuata da Dedalux 10/07/13 18:12
aaa
10/07/13 21:18
netarrow
Vediamo se questo caso particolare ti chiarifica.

Le interfacce sono chiamate, specialmente in alcuni contesti, anche contratto. Questo perchè di fatto è come definire un accordo tra due parti:

- un oggetto che consuma una o più funzionalità definite da un altro (chiama il metodo)
- un oggetto che offre una o più funzionalità (implementa il metodo)

Quindi se poniamo che lo sviluppo dei due oggetti è assegnato a te il primo a me il secondo, e lo sviluppo sarà in parallelo, io e te dovremo poter lavorare accordandoci su qualche cosa. E questa coa è proprio l'interfaccia da utilizzare.

Il tuo codice customer farà riferimento sempre e solo ad una ipotetica IOperationsBlaBla e sarà quindi completamente agnostico da cosa ci sarà dentro il metodo.

Per intenderci:

public void DoSomething(IOperationsBlaBla operations) 
{
...
    operations.Method1();
...
}


Io farò una classe che la implementerà, quindi darà dei comportamenti:

public class NetarrowOperations : IOperationsBlaBla 
{
...
public void Method1() {
  ... // implementazione qui
}
...
}


A questo punto il tuo codice lavorando su una IOperationsBlaBla potrà accettare la mia classe e lavorare con essa, ma al tempo stesso esserne slegato.

Se infatti un domani tu farai la tua versione della classe implementando la stessa interfaccia la passerai al posto della mia e il tuo vecchio codice non richiederà modifiche.
aaa
12/07/13 11:24
tuttodiMC
netarrow mi stai quindi dicendo che l'interfaccia viene utilizzata nello sviluppo in team più che in quello da singolo programmatore?

aaa
12/07/13 12:45
netarrow
No, devono essere utilizzate il più possibile in generale per mantenere il codice loose coupled, estendibile, riutilizzabile manutenibile e testabile. Un caso specifico e concreto di esempio è quello che ti ho fatto io ma il messaggio non voleva essere che in team le usi di più

Lo scopo è produrre un codice che segua i principi SOLID se vuoi approfondire: en.wikipedia.org/wiki/…_(object-oriented_design)
Ultima modifica effettuata da netarrow 12/07/13 12:45
aaa