PDA

Visualizza versione completa : [C#]Interfaccie


Kleidemos
30-01-2003, 15.17.50
A che servono le interfaccie?
Da quel che ho capito dovrebbero essere classi astratte.
Ma a cosa servono????????'

Chi mi posta un esempio:D



Ciao&Tnk

P8257 WebMaster
30-01-2003, 16.56.41
Il concetto di interfaccia è molto complesso, occorrerebbe fare degli schemi su carta e un disegno per poterlo spiegare a fondo come merita. A grandissime linee, l'interfaccia è una struttura "astratta" (DA NON CONFONDERE con la classe astratta) attraverso cui ci si può interfacciare appunto, per raggiungere e chiamare i metodi implementati nelle classi che a loro volta forniscono implementazione della stessa interfaccia.

Ad esempio (linguaggio IDL di Java)

interface Pippo
{
long SignatureDelMetodo1(in String parametro1);
bool SignatureDelMetodo2();

...
}


Nell'interfaccia NON può esserci codice eseguibile, essa deve ospitare le signature dei metodi che saranno implementati nelle classi, tuttavia la sintassi e la struttura del codice interno, fanno assomigliare tuto questo alla definizione di una classe, ma non è propriamente così.

Uno dei concetti importantissimi che si legano all'interfaccia è senz'altro quello dell'ereditarietà multipla, interfacciando infatti implementazioni provenienti da classi diverse si ottiene lo stesso effetto dell'ereditarietà multipla che in Java (o C#) non è supportata e che crea difficoltà e problemi se non usata a dovere (programmatori C++ ;))

Il discorso è talmente ampio e complesso che non si esaurisce qui, basti pensare che l'intera architettura del linguaggio si basa su interfacce e con esse si introduce inevitabilmente anche il concetto di polimorfismo

Bye :cool:

Kleidemos
30-01-2003, 18.34.33
è tipo i files .h con le dicharazioni delle funzioni in C?

P8257 WebMaster
30-01-2003, 19.05.44
Originariamente inviato da Kleidemos
è tipo i files .h con le dicharazioni delle funzioni in C?

Mon proprio, ..
Il C è un linguaggio procedurale, qui si parla di incapsulamento .. l'incapsulamento a livello di oggetti è la classe, a livello di classe è l'interfaccia.
Inoltre i file header di C, permettono di istruire il preprocessore su azioni da intraprendere in determinate condizioni, l'interfaccia in senso "ortodosso" invece, non contiene codice eseguibile, ma solo la "signature" dei metodi.
Tutto questo permette di definire strutture complesse ma rigide e soprattutto auto-documentanti (self-documenting) in grado di circoscrivere problemi e aumentare al massimo la ri-usabilità del codice

Bye :cool:

Kleidemos
30-01-2003, 19.10.20
nn hai un esmpio(di codice) banale per farmi capire?

P8257 WebMaster
30-01-2003, 20.22.42
Non ho voglia di scartabellare tra i sorgenti, ma visto che ciò che chiedi è un esempio di struttura del tutto, mi invento qualcosa.. utilizzo Java e IDL perché sono quelli che mi saltano alla mente più facilmente, noterai poche differenze con C#, come già discusso.

Semplice interfaccia (IDL):

interface Pippo
{
String[] SignatureDelMetodo1(in long parametro1, in String Par2);
void SignatureDelMetodo2();
}


L'interfaccia è un modello, una sorta di "contratto" che si fa con il compilatore Java e con il Runtime, nel quale si istanziano dei metodi che poi si "promette" di implementare successivamente nelle classi che comporranno il progetto.
Questa visione atipica fornisce molto bene l'idea di interfaccia come modello incapsulatorio appunto, come mezzo per interfacciarsi al di sopra delle mere classi per ottenere codice sempre più ri-usabile (l'esempio delle applicazioni basate su CORBA mi salta subito agli occhi, perché in esse le interfacce consentono di "mettere a disposizione" del chiamante metodi esposti e ri-usabili che sono definiti in moduli diversi).

Ogni interfaccia DEVE avere la sua implementazione che viene realizzata con le metodologie classiche della programmazione ad oggetti.

Implementazione:

public class Classe implements Pippo
{

// costruttore
public void Classe()
{
}

public String[] SignatureDelMetodo1(int parametro1, String Par2)
{
.. implemento il metodo
}

public void SignatureDelMetodo2()
{
.. implemento il metodo
}
}


Ogni interfaccia DEVE avere l'implementazione per TUTTI i metodi definiti, altrimenti viene restituito un messaggio di errore dal compilatore.

L'ereditarietà multipla si ottiene in quanto è possibile implementare con una stessa classe più interfacce, che quindi "espongono" metodi derivanti da implementazioni diverse.. da qui la partenza per l'analisi del concetto di polimorfismo.

Ho sintetizzato, l'argomento è vastissimo e molto complesso in realtà.

Bye :cool:

Kleidemos
30-01-2003, 20.32.59
cioe io ho per esempio

interface Animale
{
void Muovi();
}

class Cane:Animale {
void Muovi(){
Console.WriteLine("Me sto a movere");
}
public static void Main() {
Cane inter = new Cane();
Cane.Muovi();
}
}


è esatto?

P8257 WebMaster
30-01-2003, 20.35.23
.. Si, ma in questo caso l'interfaccia è inutile, perché non ne usufruisci.. chiami il metodo e il costruttore all'interno della stessa classe.

Bye :cool:

P8257 WebMaster
30-01-2003, 20.37.55
.. senza contare che il costruttore manca, io consiglio sempre di ridefinirlo, anche se vuoto

Bye :cool:

Kleidemos
30-01-2003, 20.38.19
Originariamente inviato da P8257 WebMaster
.. Si, ma in questo caso l'interfaccia è inutile, perché non ne usufruisci.. chiami il metodo e il costruttore all'interno della stessa classe.

Bye :cool:


come mi tornerebbe utile in questo caso?

P8257 WebMaster
30-01-2003, 20.45.08
..In questo caso non è utile infatti, di solito ci si "rivolge" all'interfaccia per chiamarne i metodi definiti e non alla classe che li implementa, altrimenti si annulla lo stesso scopo dell'inetfaccia.

Usala come una classe


Animale pippo = new Cane();

E' il concetto delle variabili reference e dei tipi non primitivi, ti ci ritrovi?

Bye :cool:

Kleidemos
30-01-2003, 20.47.06
per problemi di temòpo nn posso leggere il libro e sto provando a cavarmela da solo:D

Sono skarso vero?:(

P8257 WebMaster
31-01-2003, 01.13.29
Originariamente inviato da Kleidemos
per problemi di temòpo nn posso leggere il libro e sto provando a cavarmela da solo:D

Sono skarso vero?:(

Ma ci mancherebbe altro..
Penso che nessuno sia nato con il dono "divino" di programmare (a parte qualche vecchia conoscenza qui sul forum, che di divino penso abbia ben poco).. quindi il mio consiglio è di leggere a fondo le pubblicazioni, i libri e soprattutto l'evoluzione dei paradigmi dal procedurale all'object oriented.

Penso che per un approccio di tipo autodidattico, la programmazione procedurale si presti maggiormente, per l'object oriented, il rischio è quello di acquisire concetti non proprio esatti e di adattaer la struttura OOP forzandola al modello procedurale.

Mi salta all'occhio l'esempio del generatore di password che avevi postato (non avertene a male, non è critica o valutazione), in esso ci ho notato una forzatura del paradigma procedurale specie quando chiami i metodi interni alle classi o usi il costruttore per definire elementi del tutto estranei al processo (come la stessa UI).

Il mio incoraggiamento e consiglio è quello di continuare su questa strada coadiuvando il tutto con una buona lettura.

Bye :cool:

Kleidemos
31-01-2003, 06.50.15
grazie per i tuoi consigli ne faro uso!
Solo che la scuola, IV ginnasio, mi porta via molto tempo alla lettura:D

Sai di qualche sito in italiano che nn sia http://www.c-sharpcorner.com/ (è in inglese..........capisco quasi tutto ma poi nn sono sicuro ) ??????






Tnk10000000000000&Ciao