View Full Version : Interfaccia in java
da wikipedia
Nella programmazione, in particolare in quella orientata agli oggetti, l'interfaccia di una classe è formata dall'insieme dei dati e dei metodi visibili all'esterno di un oggetto.
http://it.wikipedia.org/wiki/Interfaccia
e poi
Il termine interfaccia viene spesso utilizzato nelle discipline tecniche con il significato di dispositivo fisico o virtuale che permette la comunicazione fra due o più entità di tipo diverso;
http://it.wikipedia.org/wiki/Interfaccia_%28informatica%29
non ci vedo molti punti in comune, sembra quasi un termine abusato(quasi).
Mi chiedevo se in java, dato che è un pò che non lo uso, se è il modo escogitato per poter usare metodi di altre classi all'interno di una propria classe e cioè: nella mia classe specifico che voglio implementare una particolare classe Implements, poi dichiaro i metodi astratti(solo lo scheletro=le definizioni dei metodi) e questi diventano disponibili nella mia classe!
:stordita:
Solo con le interfacce puoi fare "implements",
con le altre solo "extends"...
Oppure non capisco cosa vuoi dire.
Solo con le interfacce puoi fare "implements",
con le altre solo "extends"...
Oppure non capisco cosa vuoi dire.
supponiamo che tu scrivi una classe ed io voglio usare i metodi da te scritti senza però che io sappia come li hai implementati
Usare nel senso di invocare? Crei un oggetto della mia classe
e ci invochi i metodi (non statici).
Riutilizzare l'implementazione? Estendi la classe.
Usare nel senso di invocare? Crei un oggetto della mia classe
e ci invochi i metodi (non statici).
Riutilizzare l'implementazione? Estendi la classe.
ah!
Allora continua sfuggirmi il ruolo/scopo/significato di interfaccia in java.
mad_hhatter
23-03-2007, 09:19
da wikipedia
Nella programmazione, in particolare in quella orientata agli oggetti, l'interfaccia di una classe è formata dall'insieme dei dati e dei metodi visibili all'esterno di un oggetto.
http://it.wikipedia.org/wiki/Interfaccia
e poi
Il termine interfaccia viene spesso utilizzato nelle discipline tecniche con il significato di dispositivo fisico o virtuale che permette la comunicazione fra due o più entità di tipo diverso;
http://it.wikipedia.org/wiki/Interfaccia_%28informatica%29
non ci vedo molti punti in comune, sembra quasi un termine abusato(quasi).
Mi chiedevo se in java, dato che è un pò che non lo uso, se è il modo escogitato per poter usare metodi di altre classi all'interno di una propria classe e cioè: nella mia classe specifico che voglio implementare una particolare classe Implements, poi dichiaro i metodi astratti(solo lo scheletro=le definizioni dei metodi) e questi diventano disponibili nella mia classe!
:stordita:
ciao, non e' un termine abusato... interfaccia e' appunto il COME due entita' possono rapportarsi una all'altra, in particolare il modo in cui possono dialogare. In questo senso si ha la nozione di interfaccia tra dispositivi fisici o vituali e anche quella di interfaccia esposta da un oggetto in un linguaggio OO: l'interfaccia e' la descrizione del modo in cui un altro oggetto puo' dialogare (cioe' utilizzare) l'oggetto in questione.
In un linguaggio OO si parla di interfaccia anche in un altro senso, intendendo una struttura logica atta a descrivere le caratteristiche comuni (e pubbliche) di una o piu' classi (le quali, appunto, implementano tale interfaccia). Ma anche qui il significato e' lo stesso: descrivere come un'entita' terza possa dialogare con gli oggetti che implementano una data interfaccia... in questo senso l'interfaccia e' come un patto stipulato tra le parti, in cui chi implementa l'interfaccia garantisce di esporre alcuni metodi e dati specificati nel contratto stesso.
Come vedi in tutti i casi si tratta di descrivere un modello di comunicazione.
In java, poi, esiste anche la classe astratta che e' una via di mezzo tra una classe e un'interfaccia. Mentre nell'interfaccia si danno solo metodi (pubblici), nella classe astratta possono esistere campi e metodi aventi qualsiasi tipo di accessibilita', ma in particolare ci saranno dei metodi astratti di cui e' data solo la dichiarazione, ma non l'implementazione, che e' demandata alle classi derivate.
mad_hhatter
23-03-2007, 09:21
supponiamo che tu scrivi una classe ed io voglio usare i metodi da te scritti senza però che io sappia come li hai implementati
questo accade normalmente, anche per i linguaggi strutturati, ma e' ancora piu' evidente in linguaggio OO
mad_hhatter
23-03-2007, 09:27
ah!
Allora continua sfuggirmi il ruolo/scopo/significato di interfaccia in java.
supponi di avere una collezione di oggetti DIVERSI ma tali per cui e' definita una relazione d'ordine totale. E tu vuoi ordinare questa collezione. non ti interessa il tipo di oggetto fintantoche tutte le classi a cui tali oggetti appartengono implementano la stessa interfaccia "Comparabile" che semplicemente ti dice che OGNI oggetto della collezione, indipendentemente dal suo tipo, presenta un metodo "compareTo(oggetto2)" che si preoccupa di stabilire una relazione d'ordine tra l'oggetto che invoca il metodo e l'oggetto oggetto2 (il quale a sua volta dovra' essere comparabile, cioe' dovra' implementare l'interfaccia Comparabile).
Sara' compito del programmatore fare in modo che il metodo lavori correttamente , ma a te, semplice utente del metodo, questo non interessa
Ancora, supponi di avere l'interafccia Studente con le due classi che la implementano: StudenteInCorso e StudenteLaureato. Supponi di dover dire a ogni tipo di studente di FareUnLavoro. E supponi che entrambi i tipi di studenti debbano svolgere i compiti A,B, ma che solo gli studenti laureati debbano fare anche il compito C... allora tu dirai soltanto a ogni studente di FareUnLavoro, sara' poi compito di ogni studente sapere che tipo di studente e' e svolgere il compito in modo corretto... lo studente laureato avra' il metodo FareUnLavoro implementato in modo da svolgere i compiti A,B,C, mentre lo studente in corso implementera' tale metodo per svolgere solo A,B... ma a te tale implementazione non interessa, ti interessa soltanto dire agli studenti di svolgere il rispettivo compito. allora tramite l'interfaccia tu te ne freghi del tipo effettivo di studente e gli dici soltanto di svolgere il compito, perche' tanto sai che per contratto (l'interfaccia) ogni studente ha un metodo chiamato FareUnLavoro... tu non ti devi preoccupare ne' del tipo di studente, ne' dell'implementazione del metodo...
Senza interfaccia avresti dovuto porti il problema di gestire oggetti di tipo diverso.
ciao, non e' un termine abusato... interfaccia e' appunto il COME due entita' possono rapportarsi una all'altra, in particolare il modo in cui possono dialogare. In questo senso si ha la nozione di interfaccia tra dispositivi fisici o vituali e anche quella di interfaccia esposta da un oggetto in un linguaggio OO: l'interfaccia e' la descrizione del modo in cui un altro oggetto puo' dialogare (cioe' utilizzare) l'oggetto in questione.
In un linguaggio OO si parla di interfaccia anche in un altro senso, intendendo una struttura logica atta a descrivere le caratteristiche comuni (e pubbliche) di una o piu' classi (le quali, appunto, implementano tale interfaccia). Ma anche qui il significato e' lo stesso: descrivere come un'entita' terza possa dialogare con gli oggetti che implementano una data interfaccia... in questo senso l'interfaccia e' come un patto stipulato tra le parti, in cui chi implementa l'interfaccia garantisce di esporre alcuni metodi e dati specificati nel contratto stesso.
Come vedi in tutti i casi si tratta di descrivere un modello di comunicazione.
In java, poi, esiste anche la classe astratta che e' una via di mezzo tra una classe e un'interfaccia. Mentre nell'interfaccia si danno solo metodi (pubblici), nella classe astratta possono esistere campi e metodi aventi qualsiasi tipo di accessibilita', ma in particolare ci saranno dei metodi astratti di cui e' data solo la dichiarazione, ma non l'implementazione, che e' demandata alle classi derivate.
sarà perchè ho in mente due dispositivi elettronici incompatibili e che grazie ad una interfaccia che fa da ponte tra i due dispositivi traducendo in ambo le direzioni le reciproche richieste, possono parlarsi.
Usare nel senso di invocare? Crei un oggetto della mia classe
e ci invochi i metodi (non statici).
Riutilizzare l'implementazione? Estendi la classe.
ma se volessi usare un metodo della tua classe su un oggetto della mia classe senza dover istanziare un oggetto della tua classe ?
Magari un metodo di riordinamento presente nella tua classe.
Magari non è fattibile :stordita:
supponi di avere una collezione di oggetti DIVERSI ma tali per cui e' definita una relazione d'ordine totale. E tu vuoi ordinare questa collezione. non ti interessa il tipo di oggetto fintantoche tutte le classi a cui tali oggetti appartengono implementano la stessa interfaccia "Comparabile" che semplicemente ti dice che OGNI oggetto della collezione, indipendentemente dal suo tipo, presenta un metodo "compareTo(oggetto2)" che si preoccupa di stabilire una relazione d'ordine tra l'oggetto che invoca il metodo e l'oggetto oggetto2 (il quale a sua volta dovra' essere comparabile, cioe' dovra' implementare l'interfaccia Comparabile).
Sara' compito del programmatore fare in modo che il metodo lavori correttamente , ma a te, semplice utente del metodo, questo non interessa
Ancora, supponi di avere l'interafccia Studente con le due classi che la implementano: StudenteInCorso e StudenteLaureato. Supponi di dover dire a ogni tipo di studente di FareUnLavoro. E supponi che entrambi i tipi di studenti debbano svolgere i compiti A,B, ma che solo gli studenti laureati debbano fare anche il compito C... allora tu dirai soltanto a ogni studente di FareUnLavoro, sara' poi compito di ogni studente sapere che tipo di studente e' e svolgere il compito in modo corretto... lo studente laureato avra' il metodo FareUnLavoro implementato in modo da svolgere i compiti A,B,C, mentre lo studente in corso implementera' tale metodo per svolgere solo A,B... ma a te tale implementazione non interessa, ti interessa soltanto dire agli studenti di svolgere il rispettivo compito. allora tramite l'interfaccia tu te ne freghi del tipo effettivo di studente e gli dici soltanto di svolgere il compito, perche' tanto sai che per contratto (l'interfaccia) ogni studente ha un metodo chiamato FareUnLavoro... tu non ti devi preoccupare ne' del tipo di studente, ne' dell'implementazione del metodo...
Senza interfaccia avresti dovuto porti il problema di gestire oggetti di tipo diverso.
quindi la parola chiave è DIVERSI ?
mad_hhatter
23-03-2007, 09:39
ma se volessi usare un metodo della tua classe su un oggetto della mia classe senza dover istanziare un oggetto della tua classe ?
Magari un metodo di riordinamento presente nella tua classe.
Magari non è fattibile :stordita:
piano, il protocollo di comunicazione tra oggetti e' che un oggetto puo' instanziarne un altro e dirgli di invocare un metodo, ma l'implementazione a te resta sconosciuta e inaccessibile. non puoi accedere al codice, devi creare un oggetto e usarlo. e basta
mad_hhatter
23-03-2007, 09:42
quindi la parola chiave è DIVERSI ?
si... il concetto chiave e' quello di rendere pubbliche le caratteristiche COMUNI nascondendo le differenze. serve a mascherare le differenze facendo apparire cose diverse come appartenenti a un TIPO unico e piu' astratto (come nel caso dello studente: ti interessa la parola studente, mentre vuoi ignorare di che tipo di studente stiamo parlando)
mad_hhatter
23-03-2007, 09:44
ma se volessi usare un metodo della tua classe su un oggetto della mia classe senza dover istanziare un oggetto della tua classe ?
Magari un metodo di riordinamento presente nella tua classe.
Magari non è fattibile :stordita:
puoi usare un metodo di una classe senza istanziare oggetti di quel tipo solo se il metodo e' statico! ma comunque puoi solo usarlo cosi' com'e', non puoi prenderne il codice che lo implementa e modificarlo a tuo piacimento
ma se volessi usare un metodo della tua classe su un oggetto della mia classe senza dover istanziare un oggetto della tua classe ?
Magari un metodo di riordinamento presente nella tua classe.
Magari non è fattibile :stordita:
Nel caso specifico implementi l'interfaccia Comparable, crei un array
dei tuoi oggetti e lo riordini con il metodo statico Arrays.sort.
mad_hhatter
23-03-2007, 09:47
sarà perchè ho in mente due dispositivi elettronici incompatibili e che grazie ad una interfaccia che fa da ponte tra i due dispositivi traducendo in ambo le direzioni le reciproche richieste, possono parlarsi.
tu pensa in questi termini allora:
un oggetto e' una scatola nera di cui non conosci nulla se non l'interfaccia che espone, cioe' i metodi e i dati pubblici (cioe' visibili, appunto)
l'interfaccia e' quel qualcosa che ti permette di usare quella scatola nera (in questo senso e' leggermente diverso dal tuo concetto di interfaccia).
tieni presente che usare nel caso di oggetti significa un qualcosa di monodirezionale: io prendo un oggetto e so come usarlo: so cosa puo' fare e che cosa mi produce, ma non si tratta di traduzione o di comunicazione bidirezionale.. in questo senso i concetti sono diversi
si... il concetto chiave e' quello di rendere pubbliche le caratteristiche COMUNI nascondendo le differenze. serve a mascherare le differenze facendo apparire cose diverse come appartenenti a un TIPO unico e piu' astratto (come nel caso dello studente: ti interessa la parola studente, mentre vuoi ignorare di che tipo di studente stiamo parlando)
forse ho capito, forse.
Creo un certo numero di classi anche differenti tra loro ma in tutte implemento(Implements) la medesima interfaccia esempio: Comparable e grazie a questa posso riordinare oggetti anche diversi tra loro che però, credo debbano possedere almeno una propietà in comune, adesempio il peso.
Non potrei riordinare pere con mele credo (colore dei capelli, peso di un automobile). :stordita:
Ma l'implementazione di riordino non la devo implementare io, giusto ? :stordita:
mad_hhatter
23-03-2007, 12:13
forse ho capito, forse.
Creo un certo numero di classi anche differenti tra loro ma in tutte implemento(Implements) la medesima interfaccia esempio: Comparable e grazie a questa posso riordinare oggetti anche diversi tra loro che però, credo debbano possedere almeno una propietà in comune, adesempio il peso.
Non potrei riordinare pere con mele credo (colore dei capelli, peso di un automobile). :stordita:
Ma l'implementazione di riordino non la devo implementare io, giusto ? :stordita:
hai capito.
certo, nel caso del Comparable tutti gli oggetti devono avere un qualcosa che permetta di confrontarli... in effetti, come esempio forse non è il migliore... molto meglio quello degli studenti.
Il succo è che l'interfaccia ti mette in grado di lavorare con tipi di oggetti diversi permettendoti di vederli in modo coerente, introducendo un tipo di dato più astratto che accomuna tutti gli oggetti. in questo senso l'architettura e la semantica degli oggetti deve essere tale da permettere questo tipo di lavoro (come hai detto tu, i comparable devo avere un dato comune che possa essere usato per fare la comparazione... ma questo è un esempio specifico; nell'esempio degli studenti a te serviva solo un metodo comune, nient'altro. per il resto i due tipi di studenti potevano essere due cose molto diverse tra loro!)
L'interfaccia così come la classe astratta servono a introdurre un livello di astrazione e di aggregazione tale da mascherare le peculiartà (a cui non sei interessato come UTENTE di tali oggetti) e a evidenziare, rendendo esplcite, le caratteristiche comuni a tutti i diversi tipi di oggetto (caratteristiche a cui sei interessato!!!).
Per quanto riguarda l'implementazione...
se tu hai un metodo Ordina() che accetta come parametro una collezione di Comparable e tu vuoi usarlo semplicemente, non ti interessa l'implementazione. Sai solo che serve a ordinare oggetti che devono avere determinate caratteristiche e, finché ce le hanno, puoi ordinare tutti i tipi di oggetto che vuoi. Se però sei interessato a CREARE un nuovo tipo di oggetto che sia comparabile con altri già esistenti (secondo la relazione d'ordine definita dall'interfaccia Comparable), allora dovrai appunto creare un metodo "compareTo" (ad esempio) che è quel famoso metodo richiesto dall'interfaccia e implementarlo (stavolta si) in modo tale da svolgere il compito che ti sei prefisso.
Come vedi, il ruolo di un'interfaccia cambia a seconda del fatto che tu voglia soltanto usarla oppure che tu voglia ampliare l'insieme dei tipi particolari che fanno parte del concetto piu astratto il cui nome è il nome dell'interfaccia (in questo caso: l'insieme degli oggetti Comparabili)
mad_hhatter
23-03-2007, 12:16
l'interfaccia, infatti, è lo strumento, o uno degli strumenti, attraverso cui si esplica il concetto, importantissimo nella programmazione OO, di POLIMORFISMO.
Se hai già esperienza di questo termine spero di averti chiarito di più le cose. Nel caso fosse una parola nuova, semplicemente fai finta che non te l'abbia mai nominata :)
l'interfaccia, infatti, è lo strumento, o uno degli strumenti, attraverso cui si esplica il concetto, importantissimo nella programmazione OO, di POLIMORFISMO.
Se hai già esperienza di questo termine spero di averti chiarito di più le cose. Nel caso fosse una parola nuova, semplicemente fai finta che non te l'abbia mai nominata :)
mi ricordo che era un qualcosa legato ai metodi con stesso nome ma comportamento leggermente diverso :stordita:
L'interfaccia Java e l'interfaccia di cui parla wikipedia sono due cose diverse. L'interfaccia di wikipedia è riferibile all'insieme di metodi e campi pubblici di una classe Java.
L'interfaccia Java è un animale a sè. Esiste per una ragione tecnica (la dichiarazione di una variabile di tipo interfaccia non comporta caricamento di classi) e occupa un posto di rilievo in teoria.
Gli oggetti non sono scatole nere. Sono scatole trasparenti. La differenza tra un oggetto e la categoria a cui appartiene, infatti, sta in ciò che l'oggetto definisce i comportamenti che la sua categoria dichiara. Dire che la definizione contenuta in un oggetto è irrilevante significa dire che il tratto differenziale tra categoria e oggetto non è essenziale. A questo punto bisognerebbe allora dire o che esiste qualche altro tratto distintivo o che categoria e oggetto sono la stessa cosa. Posto che la seconda è assurda, la domanda allora è: se gli oggetti sono scatole nere, cosa differenzia un oggetto dalla categoria a cui appartiene?
Usare i metodi di altre classi all'interno di una propria classe. Dipende da cosa intendi per usare.
Java non è un linguaggio funzionale: non possiede il concetto di funzione come tipo (le funzioni non sono dati computabili).
Non solo non puoi prendere una funzione dichiarata e definita in una classe e usarla in un'altra classe ma neppure puoi "dire" di avere una funzione dichiarata e definita in una classe. Manca proprio il materiale di base :D.
Ciò che puoi fare, essendo Java un linguaggio orientato agli oggetti, è dichiarare una categoria di oggetti funzione. A quel punto hai mano libera.
[P.s.] Più che "infatti" ci andrebbe "secondo quanto è possibile desumere dalla letteratura". Dunque più che infatti è inteorie.
mad_hhatter
23-03-2007, 13:51
si, anche questo... ma è la parte meno potente...
supponi di avere l'interfaccia Studente, e due classi che la implementano: StudenteOrdinario, StudenteLaureato.
Tu puoi dichiarare un oggetto di tipo Studente. In questo modo avrai un riferimento in grado di puntare sia a un oggetto StudenteOrdinario, sia StudenteLaureato.
In parole povere puoi avere:
StudenteLaureato sl = new StudenteLaureato();
StudenteOdinario so = new StudenteOrdinario();
Studente s;
s = so;
s = sl;
Bene, ora immagina che l'interfaccia Studente dichiari un metodo FaiQualcosa() e che tale metodo sia implementato in modo DIVERSO nella classe StudenteOrdinario e StudenteLaureato.
Bene, il polimorfismo, sfruttando l'interfaccia, ti permette di scrivere semplicemente
s.FaiQualcosa();
e il sistema (a compile-time o, addirittura, a runtime in certe situazioni) si arrangia a invocare il metodo corretto in base al fatto che s in quel momento punti uno StudenteOrdinario o uno StudenteLaureato.
Come vedi tu non ti devi preoccupare del tipo effettivo degli oggetti che tratti: l'interfaccia serve proprio a questo! ti interessa il metodo FaiQualcosa, non come è implementato nè qual'è il tipo esatto di studente che stai trattando...
mad_hhatter
23-03-2007, 13:59
Gli oggetti non sono scatole nere. Sono scatole trasparenti. La differenza tra un oggetto e la categoria a cui appartiene, infatti, sta in ciò che l'oggetto definisce i comportamenti che la sua categoria dichiara. Dire che la definizione contenuta in un oggetto è irrilevante significa dire che il tratto differenziale tra categoria e oggetto non è essenziale. A questo punto bisognerebbe allora dire o che esiste qualche altro tratto distintivo o che categoria e oggetto sono la stessa cosa. Posto che la seconda è assurda, la domanda allora è: se gli oggetti sono scatole nere, cosa differenzia un oggetto dalla categoria a cui appartiene?
Chiariamo prima di tutto i termini... cosa intendi per scatola nera o per scatola trasparente?
Cosa intendi per categoria?
Non è l'oggetto che definisce i comportamenti, ma la sua classe... l'oggetto ESPLICITA un comportamento particolare (in funzione del suo stato), ma tale comportamento è codificato dalla classe cui esso appartiene.
Cosa intendi con "Dire che la definizione contenuta in un oggetto è irrilevante"?
mi sembrava più facile pensare ad una interfaccia come un ponte tra classi differenti
mad_hhatter
23-03-2007, 14:40
mi sembrava più facile pensare ad una interfaccia come un ponte tra classi differenti
ma non lo è...
non è un ponte, perchè non si tratta di mettere d'accordo due entità su un protocollo di comunicazione bidirezionale... è qualcosa di diverso, anche se concettualmente non troppo dissimile.
pensa piuttosto all'interfaccia come a un contratto o, meglio, a un libretto di istruzioni...
Non è un obiezione personale, è una critica generale all'idea della scatola nera se applicata agli oggetti.
Intendo per scatola nera la metafora secondo cui di un oggetto è noto l'insieme dei comportamenti ma è ignoto come questi comportamenti si compiano. Chiamo dichiarazione di un comportamento l'indicazione del possesso da parte di un oggetto della capacità di interpretare un certo messaggio (il fatto che un certo metodo esista). Chiamo definizione di un comportamento l'indicazione di come quel messaggio è interpretato dall'oggetto (cosa c'è scritto dentro quel metodo). Dico che secondo la metafora della scatola nera la definizione di un comportamento è irrilevante in base al rilievo che ciò che è ignoto non può essere assunto a fondamento di una scelta o di una caratterizzazione.
Quanto al fatto che un oggetto non definisca comportamenti può essere vero in Java ma non, ad esempio, in Scala. Oserò dire di più e qui sarò tacciato di eresia :D. La differenza che sussiste tra un oggetto e una classe sta in ciò che l'oggetto definisce un comportamento che la classe dichiara e basta. Che, in Java, varrebbe come dire che le classi sono oggetti, nella forma di archetipi (esemplari completi originari), le istanze cloni e le interfacce classi.
MisterX. Anche io preferisco la definizione dell'interfaccia (java) come "ponte tra". Precisamente io reputo un'interfaccia Java come la dichiarazione di una relazione che intercorre tra due o più classi Java.
Comunque è un topic interessantissimo.
mad_hhatter
23-03-2007, 15:23
Non è un obiezione personale, è una critica generale all'idea della scatola nera se applicata agli oggetti.
Intendo per scatola nera la metafora secondo cui di un oggetto è noto l'insieme dei comportamenti ma è ignoto come questi comportamenti si compiano. Chiamo dichiarazione di un comportamento l'indicazione del possesso da parte di un oggetto della capacità di interpretare un certo messaggio (il fatto che un certo metodo esista). Chiamo definizione di un comportamento l'indicazione di come quel messaggio è interpretato dall'oggetto (cosa c'è scritto dentro quel metodo). Dico che secondo la metafora della scatola nera la definizione di un comportamento è irrilevante in base al rilievo che ciò che è ignoto non può essere assunto a fondamento di una scelta o di una caratterizzazione.
Quanto al fatto che un oggetto non definisca comportamenti può essere vero in Java ma non, ad esempio, in Scala. Oserò dire di più e qui sarò tacciato di eresia :D. La differenza che sussiste tra un oggetto e una classe sta in ciò che l'oggetto definisce un comportamento che la classe dichiara e basta. Che, in Java, varrebbe come dire che le classi sono oggetti, nella forma di archetipi (esemplari completi originari), le istanze cloni e le interfacce classi.
MisterX. Anche io preferisco la definizione dell'interfaccia (java) come "ponte tra". Precisamente io reputo un'interfaccia Java come la dichiarazione di una relazione che intercorre tra due o più classi Java.
Comunque è un topic interessantissimo.
certo che non è una critica personale, ma volevo prima stabilire un linguaggio comune...
comunque, vuoi per la mia inesperienza, non riesco bene ad afferrare il senso della prima parte del tuo discorso... sui termini siamo d'accordo, ma dal punto di vista di un'entità utente di un oggetto qual è la necessità di conoscere il comportamento di quell'oggetto a livello di implementazione di un suo comportamento... come utente io sono interessato a fornire un certo input e mi attendo un risultato avente determinate caratteristiche, ma non vedo perchè dovrebbe interessarmi il modo in cui l'oggetto mi fornisce il risultato... anzi, mi pare che una regola importante sia quella di avere il minimo accoppiamento tra classi diverse... quindi, conoscendoti di fama, assumo di non aver capito cosa tu intendessi e ti chiedo, allora, cosa vuol dire che un oggetto è una scatola trasparente.
Non conosco Scala, quindi purtroppo ho un livello di astrazione e di definizione dei concetti diverso dal tuo esono perciò portato a definire un oggetto come un'entità fisica le cui proprietà e comportamenti sono delineati dalla sua classe. Il comportamento di uno specifico oggetto può variare da quello di un altro oggetto della stessa classe, per quanto riguarda la mia attuale conoscenza, solo in base al diverso stato degli oggetti, o alla differenza dei parametri di invocazione dei metodi, ma non a livello di implementazione generale di tali comportamenti (come definiti nella classe).
Ma scala è OO o Basato sugli oggetti (anche se mi sfugge la differenza, nn avendo esperienza del secondo tpo di linguaggi)
mad_hhatter
23-03-2007, 15:24
l'interfaccia java è si la dichiarazione di una relazione tra classi, ma tra classi che implementano tale interfaccia, non tra la classe utente e la classe utilizzata
... la dichiarazione di una variabile di tipo interfaccia non comporta caricamento di classi...
Non carica il .class dell'interfaccia?
xlovaz: classe nel senso di classe Java.
Al massimo mi si può conoscere per fame. Ma per fama proprio no :D.
Uso il termine scatola trasparente per contrasto con la scatola nera. Potendo userei semplicemente "oggetto", nel senso di ciò che possiede un insieme di comportamenti (cosa fa) definiti (come lo fa).
Dico che la scatola nera è la categoria a cui appartiene l'oggetto e la scatola trasparente è l'oggetto. Cioè la categoria dichiara l'insieme di comportamenti posseduti da ogni suo oggetto e l'oggetto definisce i comportamenti che ha in quanto appartenente ad una categoria. Definisce nel senso più pieno: ho questo comportamento e lo porto a termine in questo modo.
Chiarisco quello che intendo per "definizione di un comportamento".
E' come avere due oggetti Logger. In quanto Logger entrambi possono "log(message)" ma uno scrive quel messaggio su un file e uno lo scrive sulla console. Qual'è la differenza tra il logger che scrive sul file e il logger che scrive sulla console? Entrambi loggano, ma lo fanno in modo diverso.
Dal punto di vista dell'utente di un Logger può non interessare questa diversità di comportamento. Anzi, siccome disaccoppiare è effettivamente cosa buona e giusta, sarebbe meglio che non gli interessasse. Ma c'è qualcuno a cui interessa. Nel nostro caso, a chi fornirà il logger: la scelta di chi creerà il logger è specificamente guidata non da una diversità nella capacità di fare qualcosa ma da una diversità nel modo in cui qualcosa è fatto.
Una nota grossa come una casa: non parlo di oggetto nel senso Java del termine. Parlo di oggetto nel senso comune del termine: l'esemplare di una specie. Cioè l'oggetto dell'orientamento agli oggetti, non l'oggetto del linguaggio di programmazione Java.
Scala è un linguaggio orientato agli oggetti e funzionale. Personalmente non ho mai capito la nozione di linguaggio basato sugli oggetti.
mad_hhatter
23-03-2007, 17:24
xlovaz: classe nel senso di classe Java.
Al massimo mi si può conoscere per fame. Ma per fama proprio no :D.
Uso il termine scatola trasparente per contrasto con la scatola nera. Potendo userei semplicemente "oggetto", nel senso di ciò che possiede un insieme di comportamenti (cosa fa) definiti (come lo fa).
Dico che la scatola nera è la categoria a cui appartiene l'oggetto e la scatola trasparente è l'oggetto. Cioè la categoria dichiara l'insieme di comportamenti posseduti da ogni suo oggetto e l'oggetto definisce i comportamenti che ha in quanto appartenente ad una categoria. Definisce nel senso più pieno: ho questo comportamento e lo porto a termine in questo modo.
Chiarisco quello che intendo per "definizione di un comportamento".
E' come avere due oggetti Logger. In quanto Logger entrambi possono "log(message)" ma uno scrive quel messaggio su un file e uno lo scrive sulla console. Qual'è la differenza tra il logger che scrive sul file e il logger che scrive sulla console? Entrambi loggano, ma lo fanno in modo diverso.
Dal punto di vista dell'utente di un Logger può non interessare questa diversità di comportamento. Anzi, siccome disaccoppiare è effettivamente cosa buona e giusta, sarebbe meglio che non gli interessasse. Ma c'è qualcuno a cui interessa. Nel nostro caso, a chi fornirà il logger: la scelta di chi creerà il logger è specificamente guidata non da una diversità nella capacità di fare qualcosa ma da una diversità nel modo in cui qualcosa è fatto.
Una nota grossa come una casa: non parlo di oggetto nel senso Java del termine. Parlo di oggetto nel senso comune del termine: l'esemplare di una specie. Cioè l'oggetto dell'orientamento agli oggetti, non l'oggetto del linguaggio di programmazione Java.
Scala è un linguaggio orientato agli oggetti e funzionale. Personalmente non ho mai capito la nozione di linguaggio basato sugli oggetti.
si, ora ho capito il tuo filo logico e mi trovo perfettamente d'accordo con te.
quanto alla tua nota mi sorge un dubbio: parlando di oggetti java io penso agli oggetti dell'orientamento agli oggetti... quindi, c'è una differenza tra le due cose?
quanto ai linguaggi basati sugli oggetti sono felice di aver trovato un così illustre compagno di viaggio :)
ma non lo è...
non è un ponte, perchè non si tratta di mettere d'accordo due entità su un protocollo di comunicazione bidirezionale... è qualcosa di diverso, anche se concettualmente non troppo dissimile.
pensa piuttosto all'interfaccia come a un contratto o, meglio, a un libretto di istruzioni...
mi serve come termine per riuscire a memorizzare il significato di interfaccia :stordita:
Abbiamo 2 classi: Aerei e FigurePiane, entrambe implementano l'interfaccia MiaInterfaccia che possiede il metodo CalcoloArea.
Posso istanziare oggetti di tipo aereo e oggetti di tipo figure piane e grazie all'interfaccia calcolare l'area totale di tutti e due gli oggetti anche se differenti, almeno, così ho capito.
L'implementazione dei rispettivi metodi per aereo e figura piana, vanno implementata nelle rispettive classi, sarà poi lavoro dell'interfaccia, penso, usare l'uno o l'altro senza che io me ne deva occupare.....
Se non è così, non ho capito un cavolo :muro:
mad_hhatter
23-03-2007, 18:10
mi serve come termine per riuscire a memorizzare il significato di interfaccia :stordita:
Abbiamo 2 classi: Aerei e FigurePiane, entrambe implementano l'interfaccia MiaInterfaccia che possiede il metodo CalcoloArea.
Posso istanziare oggetti di tipo aereo e oggetti di tipo figure piane e grazie all'interfaccia calcolare l'area totale di tutti e due gli oggetti anche se differenti, almeno, così ho capito.
L'implementazione dei rispettivi metodi per aereo e figura piana, vanno implementata nelle rispettive classi, sarà poi lavoro dell'interfaccia, penso, usare l'uno o l'altro senza che io me ne deva occupare.....
Se non è così, non ho capito un cavolo :muro:
è esattamente così.
Detto ciò, non è propriamente l'interfaccia a occuparsi di chiamare il metodo giusto, ma il compilatore o l'interprete (a seconda del momento in cui la decisione viene presa). Ma questo è abbastanza inessenziale al fine della comprensione del concetto di interfaccia, quindi nn preoccupartene.
Quello che mi preme è farti capire il contesto in cui è utile un'interfaccia come tu l'hai descritta. Se devi soltanto calcolare l'area di un aereo o di una figura piana, ha poco senso ricorrere a un'interfaccia che astragga i due elementi in un'entità di livello più alto. Cioè, le caratteristiche comuni non vanno evidenziate e aggregate sempre e comunque, ma solo quando è opportuno! Quando lo è? Per esempio quando tu abbia una collezione di oggetti aereo e di figure piane e per ognuno di tali oggetti tu debba calcolare l'area.... o quando hai necessità di rendere il codice flessibile rispetto all'introduzione futura di nuovi oggetti pure dei quali dovrai calcolare l'area, tanto per fare 2 esempi
In ogni caso, quello che hai detto tu è corretto
Per quanto mi pare di capire, nelle specifiche di alcuni linguaggi di programmazione, penso a C, C++ e Java, il termine oggetto è usato con riferimento alla definizione che ne da la teoria dei tipi. Un tipo [di dato] è la definizione di un insieme di operazioni ed il dato è un valore a sono applicabili quelle operazioni.
In questo ambito, oggetto è il valore a cui sono applicabili le operazioni definite nella classe di appartenenza.
[p.s.] riposta al messaggio di...due messaggi fa
mad_hhatter
23-03-2007, 18:35
Per quanto mi pare di capire, nelle specifiche di alcuni linguaggi di programmazione, penso a C, C++ e Java, il termine oggetto è usato con riferimento alla definizione che ne da la teoria dei tipi. Un tipo [di dato] è la definizione di un insieme di operazioni ed il dato è un valore a sono applicabili quelle operazioni.
In questo ambito, oggetto è il valore a cui sono applicabili le operazioni definite nella classe di appartenenza.
[p.s.] riposta al messaggio di...due messaggi fa
capito. grazie dei chiarimenti
è esattamente così.
Detto ciò, non è propriamente l'interfaccia a occuparsi di chiamare il metodo giusto, ma il compilatore o l'interprete (a seconda del momento in cui la decisione viene presa). Ma questo è abbastanza inessenziale al fine della comprensione del concetto di interfaccia, quindi nn preoccupartene.
Quello che mi preme è farti capire il contesto in cui è utile un'interfaccia come tu l'hai descritta. Se devi soltanto calcolare l'area di un aereo o di una figura piana, ha poco senso ricorrere a un'interfaccia che astragga i due elementi in un'entità di livello più alto. Cioè, le caratteristiche comuni non vanno evidenziate e aggregate sempre e comunque, ma solo quando è opportuno! Quando lo è? Per esempio quando tu abbia una collezione di oggetti aereo e di figure piane e per ognuno di tali oggetti tu debba calcolare l'area.... o quando hai necessità di rendere il codice flessibile rispetto all'introduzione futura di nuovi oggetti pure dei quali dovrai calcolare l'area, tanto per fare 2 esempi
In ogni caso, quello che hai detto tu è corretto
pensa che tutti questi concetti li devo "intercalare", passami il termine, nel concetto di qualità del software e più precisamente:
- accoppiamento
- coesione
e mi è parso di capire che le interfacce nella programmazione OO giocano un ruolo di rilievo per riuscire ad ottenere classi con basso accoppiamento ed alta coesione.
Che casotto :doh:
mad_hhatter
23-03-2007, 20:30
per curiosità, che facoltà fai? e dove?
diciamo che l'interfaccia aiuta ad abbassare l'accoppiamento, ad esempio, nascondendo le diversità tra classi diverse ma semanticamente simili.
Ricordi il mio esempio degli studenti? Se il codice che utilizza gli oggetti studente deve trattare direttamente oggetti StudenteLaureato e StudenteOrdinario sarà fortemente accoppaito a tali classi in quanto dovrà tener conto della loro struttura implementativa... se invece io lavoro frapponendo un livello di astrazione (tramite l'interfaccia Studente) ecco che io disaccoppio la classe utente dalle due classi di studenti, perchè ora potrò riguardare tali due classi come un concetto unico riducendo alminimo la necessità di conoscere nei dettagli i loro meccanismi interni.
quanto alla coesione,grazie all'interfaccia Studente nell'esempio sopra non devo più gestire elementi simili distinguendo il loro tipo effettivo: posso tenere assieme istruzioni semanticamente vicine
per curiosità, che facoltà fai? e dove?
diciamo che l'interfaccia aiuta ad abbassare l'accoppiamento, ad esempio, nascondendo le diversità tra classi diverse ma semanticamente simili.
Ricordi il mio esempio degli studenti? Se il codice che utilizza gli oggetti studente deve trattare direttamente oggetti StudenteLaureato e StudenteOrdinario sarà fortemente accoppaito a tali classi in quanto dovrà tener conto della loro struttura implementativa... se invece io lavoro frapponendo un livello di astrazione (tramite l'interfaccia Studente) ecco che io disaccoppio la classe utente dalle due classi di studenti, perchè ora potrò riguardare tali due classi come un concetto unico riducendo alminimo la necessità di conoscere nei dettagli i loro meccanismi interni.
quanto alla coesione,grazie all'interfaccia Studente nell'esempio sopra non devo più gestire elementi simili distinguendo il loro tipo effettivo: posso tenere assieme istruzioni semanticamente vicine
informatica a milano
sfrutto questo 3D e scrivo...
Un sistema complesso può essere suddiviso in parti più piccole chiamate moduli. Un sistema composto da moduli è detto modulare. Il vantaggio principale della modularità è quello di consentire di applicare il principio di separazione degli interessi in due fasi.
In una prima fase si possono trattare i dettagli di un singolo modulo separatamente, ignorando i dettagli degli altri e, in una seconda fase, si possono esaminare le caratteristiche complessive di tutti i moduli e le loro relazioni, in modo da integrarli in un sistema coerente.
Quando le due fasi vengono eseguite concentrandosi inizialmente sui moduli e quindi sulla loro composizione, diciamo che il sistema viene progettato bottom-up. Al contrario,quando scomponiamo innanzitutto un problema in moduli e ci concentriamo successivamente sulla progettazione di ciascuno di questi, il processo viene chiamato progettazione top-down.
vi sembra chiaro quello che c'è scritto ?
mad_hhatter
28-03-2007, 12:22
sfrutto questo 3D e scrivo...
Un sistema complesso può essere suddiviso in parti più piccole chiamate moduli. Un sistema composto da moduli è detto modulare. Il vantaggio principale della modularità è quello di consentire di applicare il principio di separazione degli interessi in due fasi.
In una prima fase si possono trattare i dettagli di un singolo modulo separatamente, ignorando i dettagli degli altri e, in una seconda fase, si possono esaminare le caratteristiche complessive di tutti i moduli e le loro relazioni, in modo da integrarli in un sistema coerente.
Quando le due fasi vengono eseguite concentrandosi inizialmente sui moduli e quindi sulla loro composizione, diciamo che il sistema viene progettato bottom-up. Al contrario,quando scomponiamo innanzitutto un problema in moduli e ci concentriamo successivamente sulla progettazione di ciascuno di questi, il processo viene chiamato progettazione top-down.
vi sembra chiaro quello che c'è scritto ?
a me si... anche se avrei invertito i due capoversi... a te non torna qualcosa?
PS: in ogni caso il primo capoverso è un po' (tanto) superficiale, a mio avviso
a me si... anche se avrei invertito i due capoversi... a te non torna qualcosa?
molte cose non mi tornano ed è l'estratto di un libro
Un sistema complesso può essere suddiviso in parti più piccole chiamate moduli.OK
Un sistema composto da moduli è detto modulare.
OK
Il vantaggio principale della modularità è quello di consentire di applicare il principio di separazione degli interessi in due fasi.
Il principio di separazione degli interessi tocca una vastità di punti, non capisco quindi la separazione in fasi.
In una prima fase si possono trattare i dettagli di un singolo modulo separatamente, ignorando i dettagli degli altri e, in una seconda fase, si possono esaminare le caratteristiche complessive di tutti i moduli e le loro relazioni, in modo da integrarli in un sistema coerente.
Non chiaro cosa si intende per dettagli di un modulo.
Quando le due fasi vengono eseguite concentrandosi inizialmente sui moduli e quindi sulla loro composizione, diciamo che il sistema viene progettato bottom-up. Al contrario,quando scomponiamo innanzitutto un problema in moduli e ci concentriamo successivamente sulla progettazione di ciascuno di questi, il processo viene chiamato progettazione top-down.
Qui proprio non capisco che cosa intenda :muro:
io so che:
- scomporre un problema in pezzi più semplici (progettazione top-down)
- comporre un sistema complesso da moduli esistenti (progettazione bottom-up) qindi riusabilità
ma rispetto all'ultima parte del discorso on ci vedo molti agganci :stordita:
mad_hhatter
28-03-2007, 15:04
Il vantaggio principale della modularità è quello di consentire di applicare il principio di separazione degli interessi in due fasi.
Il principio di separazione degli interessi tocca una vastità di punti, non capisco quindi la separazione in fasi.
concordo, come ti ho detto qui sono stati MOLTO superficiali... ma in pratica quello che intendono è che usare la decomposizione in sottoproblemi permette di scindere la soluzione in 2 pezzi: la suddivisione in sottoproblemi + la soluzione dei vari sottoproblemi in modo indipendente uno dall'altro... cioè fai una prima bozza di analisi del problema e poi passi a risolvere un insieme di problemi più semplici... secondo me è tutto qui (hanno usato un termine, "separazione degli interessi", troppo vasto rispetto al concetto, ben più limitato, che stavano descrivendo)
In una prima fase si possono trattare i dettagli di un singolo modulo separatamente, ignorando i dettagli degli altri e, in una seconda fase, si possono esaminare le caratteristiche complessive di tutti i moduli e le loro relazioni, in modo da integrarli in un sistema coerente.
Non chiaro cosa si intende per dettagli di un modulo.
leggilo nel senso più generico possibile: dettagli nel senso di "soluzione di quello specifico sottoproblema"
Quando le due fasi vengono eseguite concentrandosi inizialmente sui moduli e quindi sulla loro composizione, diciamo che il sistema viene progettato bottom-up. Al contrario,quando scomponiamo innanzitutto un problema in moduli e ci concentriamo successivamente sulla progettazione di ciascuno di questi, il processo viene chiamato progettazione top-down.
Qui proprio non capisco che cosa intenda :muro:
io so che:
- scomporre un problema in pezzi più semplici (progettazione top-down)
- comporre un sistema complesso da moduli esistenti (progettazione bottom-up) qindi riusabilità
ma guarda che intendete esattamente la stessa cosa. Leggi la prima frase così:
Quando le due fasi vengono eseguite concentrandosi inizialmente sui moduli e SUCCESSIVAMENTE si affronta il problema della loro AGGREGAZIONE, diciamo che il sistema viene progettato bottom-up.
beh, sono ricorso ad una videolezione per capire bene il significato :muro:
domanda: se parlo di un oggetto basandomi esclusivamente sul suo comportamento esterno e quindi senza conoscere il suo funzionamento interno, sto facendo astrazione ?
No, è data hiding.
Astrazione è prendere un insieme di caratteristiche di ciò che è particolare e considerarle come unità in quanto proprie di una generalità di cose.
No, è data hiding.
Astrazione è prendere un insieme di caratteristiche di ciò che è particolare e considerarle come unità in quanto proprie di una generalità di cose.
se parlo di un'automobile senza entrare nelle specifiche del tipo di auto ma dico che: ha 4 ruote, una carrozzeria, un motore, un volante e se pigi sull'acceleratore si muove, non è parlare in astratto di un'automobile ?
A me sembra che così dicendo stia generalizzando un oggetto e cioè facendo astrazione :stordita:
E' corretto.
Ma non stai prescindendo dal suo funzionamento. Stai considerando solo alcune delle caratteristiche della cosa particolare.
Tu hai di fronte quell'unico, preciso esemplare che è esemplare proprio perchè possiede un insieme di caratteri unici. Ha quella macchiolina di ruggine sul parafango, se l'accendi il motorino gratta per 1.34 secondi eccetera eccetera.
Astrai quando dici che quella cosa lì è un'automobile perchè ha 4 ruote, una carrozzeria, un volante e se pigi sull'acceleratore si muove. Consideri un sottoinsieme delle caratteristiche di quella particolare cosa e dichiari che tale sottoinsieme è tipico di una generalità di cose (automobile).
Prescindi dalla definizione quando dichiari che quell'unico esemplare è di colore rosso senza specificare come può quella particolare cosa essere rossa.
forse ho capito, faccio astrazione quando non parlo esclusivamente(in modo specifico) di una cosa ma generalizzo :stordita:
mad_hhatter
29-03-2007, 15:19
facciamo un esempio concreto:
abbiamo le seguenti entità: automobile, camion, furgone, bicicletta, motorino...
se considero solo il fatto che queste entità siano dei mezzi di trasporto sto facendo un'astrazione (nota che sono io che decido quali caratteristiche considerare e quali ignorare al fine di considerare tutte quelle entità, seppur diverse, come un unico concetto, appunto, più generale, più astratto).
in sostanza l'astrazione è il processo che porta a considerare un gruppo di entità diverse come un'entità unica. Tale entità non può che essere astratta (mentre le entità di partenza POSSONO essere entità concrete).
se vuoi l'astrazione è quel processo mentale che sta alla base del concetto matematico di INSIEME: un insieme in matematica è una collezione di elementi accomunati da alcune caratteristiche usate appunto per raggrupparli. L'insieme è l'astrazione di quel gruppo di elementi.
Quando invece prendi un'entità qualsiasi, astratta o concreta, e ne consideri l'interfaccia, cioè l'insieme delle caratteristiche visibili dall'esterno stai appunto considerandone l'interfaccia :) se in questo poni l'accento sul fatto che hai mascherato la struttura e il comportamento interno di tale entità allora stai parlando di INCAPSULAMENTO (il data hiding di cui parlava PGI-Bis è soltanto UNO dei modi in cui si esplica il concetto di incapsulamento)
mad_hhatter
29-03-2007, 15:22
se parlo di un'automobile senza entrare nelle specifiche del tipo di auto ma dico che: ha 4 ruote, una carrozzeria, un motore, un volante e se pigi sull'acceleratore si muove, non è parlare in astratto di un'automobile ?
A me sembra che così dicendo stia generalizzando un oggetto e cioè facendo astrazione :stordita:
la differenza è nell'INTENTO: quando fai ciò che hai scritto con l'intento di accomunare l'automobile ad altre entità diverse ma aventi un sottoinsieme comune di caratteristiche e al fine di considerare tale gruppo come un concetto unitario stai astraendo.
se invece consideri quelle caratteristiche dell'auto solo perchè sono le uniche visibile da un utente esterno allora stai parlando di interfaccia e, volendo, di incapsulamento
[Pre scriptum]Riferendomi all'ultimo messaggio di misterx...
Vorrei dirti di sì ma non so se tu abbia la certezza di aver compreso o tu stia cercando di farmi fesso :D.
E', come giustamente dici, generalizzazione. E' generalizzazione di qualcosa di concreto.
Non è un parlare dell'aria, del mondo la vita e la pace. E' la possibilità di prendere una penna e dire "ho una penna in mano" quando in realtà quello che hai in mano è un cumulo di materiale che ha certe caratteristiche che lo rendono unico.
Quando dici "ho una penna in mano" lo dici riferendoti ad una concreta penna. E' il modo in cui ti riferisci a quella penna che denota astrazione.
Puoi benissimo parlare esclusivamente di una cosa, di quella penna e non di un'altra, ma farlo in modo astratto, cioè considerando solo alcune della caratteristiche di quella concreta penna.
Il grandissimo problema dell'astrazione nell'orientamento agli oggetti, a mio modestissimo parere, è che viene spacciato come un che di eccezionale. La verità è che, per un essere umano, l'astrazione non è affatto eccezionale. E' eccezionale il contrario, cioè la specificazione.
Si butta lì la parola, "astrazione", e pare che Mosè abbia aperto le acque.
Tu esci di casa, incontri un amico e gli dice "oggi a momenti un'auto mi tira sotto" e stai facendo astrazione.
Astrai riferendoti a quella concreta cosa che a momenti ti tirava sotto indicandola come "auto". Non parli di automobili in generale: era proprio quella che ti voleva stirare. Tuttavia ne parli, la identifichi, come un'automobile.
E' importante aver ben chiaro che si parla comunque di qualcosa di determinato perchè l'uso dell'astrazione è motivato proprio dall'esistenza di questo qualcosa di concreto.
Anzi, è proprio avendo come punto di riferimento l'esistenza di questo qualcosa di concreto che diventa evidente l'utilità di astrarre.
Perchè "astrarre"? Perchè diciamo al nostro amico "un'auto mi stava tirando sotto" e non diciamo invece "835kili di materia dislocati in un volume avente le seguenti coordinate spazio temporali... a momenti mi tirava sotto"?
A scanso di equivoci, ciò che io intendo per astrazione e quello che intende mad_hatter sono due cose completamente diverse :D.
E a scanso di eventuali ulteriori equivoci generati dal mio precedente scansare, non posso affermare che ciò che intende mad_hatter per astrazione sia sbagliato.
mad_hhatter
29-03-2007, 16:59
ho riletto il post di misterx... e si, devo dire che la definizione più generale di PGI-Bis è più corretta in quest'ambito... ogni processo descrittivo, in quanto tale, è astrazione
mad_hhatter
29-03-2007, 17:00
E a scanso di eventuali ulteriori equivoci generati dal mio precedente scansare, non posso affermare che ciò che intende mad_hatter per astrazione sia sbagliato.
come mai tutte queste precauzioni? guarda che mica ti mangio se mi muovi una qualsiasi critica :D , anzi, il peggio che può succedere è che io ti ringrazi per avermi dato di che riflettere
Non è timore reverenziale :D. E' un esercizio di prudenza che deriva dalla mancanza di materiale certo. E, naturalmente, rispetto delle idee altrui.
L'orientamento agli oggetti è materia umanistica, se confrontata, ad esempio, alla prospettiva procedurale.
E manca "il manuale di orientamento agli oggetti". Quest'ultima è una cosa che occorre sempre tener presente quando se ne parla.
Quello che ha detto mad_hatter e quello che ho detto io sono cose profondamente diverse. Non posso dire tuttavia che la descrizione fatta da mad_hatter non sia riconducibile all'astrazione come elemento dell'orientamento agli oggetti perchè non c'è la definizione di "astrazione nella prospettiva orientata agli oggetti". Diamine, non c'è neppure quella di orientamento agli oggetti! :D.
mad_hhatter
29-03-2007, 17:26
Non è timore reverenziale
non vedo come potrebbe esserlo :D
mad_hhatter
29-03-2007, 17:30
Astrazione è prendere un insieme di caratteristiche di ciò che è particolare e considerarle come unità in quanto proprie di una generalità di cose.
In cosa questo differisce dalla mia definizione di astrazione?
mentre a me pare che differisca da quanto hai detto pochi post fa.
Il "Bis" c'è per un motivo: mi consente di dire che non concordo con me stesso. Nel caso di quella frase, PGI-Bis non concorda con PGI.
Quando uno tenta di riassumere un pensiero articolato in una frase ad effetto le probabilità che dica una stronzata sono altissime. Capita specialmente a quelli il cui nome inizia per P e finisce in Ierluigi.
Tengo questa parte come sempre vera:
"Astrazione è prendere un insieme di caratteristiche di ciò che è particolare e considerarle come unità"
e scarto questa come meramente eventuale:
"in quanto proprie di una generalità di cose"
mad_hhatter
29-03-2007, 18:00
ho riletto i post precedenti e, sai, non riesco a vedere una grossa differenza tra le nostre posizioni... soltanto due aspetti del processo di astrazione, ma non due definizioni incompatibili... tu invece vedi una incompatibilità?
Io ne vedo due.
La prima è nella correlazione tra astrazione ed insiemi di oggetti. Concordo, e mi sembra inevitabile, sul fatto che l'astrazione produce categorie. Non credo tuttavia che le categorie prodotte dall'astrazione siano rilevanti. L'astrazione è la riduzione della complessità di un oggetto. Incidentalmente, l'insieme delle caratteristiche dell'oggetto astratto fonda una categoria. La categoria che così si produce, tuttavia, non partecipa alla realizzazione del fine per cui io astraggo.
La seconda è che l'astrazione sia una questione di intenti: cioè astraggo se considero certe caratteristiche di un oggetto in quanto proprie di un categoria ma non astraggo se considero le stesse caratteristiche con l'intento di soprassedere sul come esse siano realizzate. Per me si ha sempre astrazione quando l'insieme delle caratteristiche considerate è minore dell'insieme di caratteristiche possedute.
Nel caso in cui questi due aspetti non siano rilevanti per la definizione che proponi allora... non ho capito niente :D.
[Pre scriptum]
Vorrei dirti di sì ma non so se tu abbia la certezza di aver compreso o tu stia cercando di farmi fesso :D.
E', come giustamente dici, generalizzazione. E' generalizzazione di qualcosa di concreto.
perchè fesso ? :confused:
Avendo una formazione itisiana e non licealscientifico mi mancano un pò questi di concetti e quindi la capacità di astrarre.
Il mio libro di ingegneria del software fa distinzione tra Astrazione e Generalità che non so se è una sorta di generalizzazione e quindi astrazione. A volte sembra che i termini si intersechino altre volte sembra di no, altre che farti fesso :muro:
Cmq è vero che molte volte si portano all'esasperazione concetti quasi intuitivi e alla fine, non li si capisce più appena si cambia il contesto in cui si utilizzano.
già che ci sono http://digilander.libero.it/daffol/img/immagine.jpg
Come mai nella classe ReCell i metodi set() e reset() sono stati ridefiniti e non si è sfruttata l'ereditarietà ?
Il problema non è dare una definizione di astrazione, darne una di ereditarietà, di polimorfismo, classe, oggetto eccetera. E' renderle coerenti. Cosa tutt'altro che semplice, soprattutto considerando la materia a cui devono essere applicate.
Nell'immagine a cui fai riferimento, la ragione per cui si è scelto di ridefinire i metodi get e set è indeterminabile.
Il rapporto lì indicato come generalizzazione è il rapporto di genere a specie che può intercorrere tra due categorie di oggetti.
Nell'immagine a cui fai riferimento, la ragione per cui si è scelto di ridefinire i metodi get e set è indeterminabile.
pensavo esistesse una ragione specifica per ridefinire uno o più metodi
mad_hhatter
30-03-2007, 12:04
Io ne vedo due.
La prima è nella correlazione tra astrazione ed insiemi di oggetti. Concordo, e mi sembra inevitabile, sul fatto che l'astrazione produce categorie. Non credo tuttavia che le categorie prodotte dall'astrazione siano rilevanti. L'astrazione è la riduzione della complessità di un oggetto. Incidentalmente, l'insieme delle caratteristiche dell'oggetto astratto fonda una categoria. La categoria che così si produce, tuttavia, non partecipa alla realizzazione del fine per cui io astraggo.
La seconda è che l'astrazione sia una questione di intenti: cioè astraggo se considero certe caratteristiche di un oggetto in quanto proprie di un categoria ma non astraggo se considero le stesse caratteristiche con l'intento di soprassedere sul come esse siano realizzate. Per me si ha sempre astrazione quando l'insieme delle caratteristiche considerate è minore dell'insieme di caratteristiche possedute.
Nel caso in cui questi due aspetti non siano rilevanti per la definizione che proponi allora... non ho capito niente :D.
quando hai risposto a misterx dicendo che quello che intendeva era data hiding ho inteso che stessi parlando della distinzione tra incapsulamento e astrazione nel senso di creare una gerarchia di classi. I miei post, infatto parlano di quel tipo di astrazione.
Se invece stiamo parlando di astrazione in senso lato allora le mie due considerazioni non vanno piu' bene e hai ragione tu nel definire astrazione un processo che mira a prescindere da alcune caratteristiche di un oggetto al fine di descriverlo, semplificarlo, e quant'altro.
pensavo esistesse una ragione specifica per ridefinire uno o più metodi
C'è sicuramente una ragione per ridefinire un metodo. Ma non puoi desumerla semplicemente dal fatto che sia stata applicata la ridefinizione. Causa ed effetto sono due cose separate per definizione.
quando hai risposto a misterx dicendo che quello che intendeva era data hiding ho inteso che stessi parlando della distinzione tra incapsulamento e astrazione nel senso di creare una gerarchia di classi. I miei post, infatto parlano di quel tipo di astrazione.
Se invece stiamo parlando di astrazione in senso lato allora le mie due considerazioni non vanno piu' bene e hai ragione tu nel definire astrazione un processo che mira a prescindere da alcune caratteristiche di un oggetto al fine di descriverlo, semplificarlo, e quant'altro.
beh, quello che intendevo io parte dalla progettazione di un software. L'astrazione mi serve per non entrare nei dettagli(tecnicismi) per poter essere capito anche da personale non tecnico.
Se un'auto la rappresento come un rettangolo ed idem, se una classe la rappresento come un rettangolo e la sua sottoclasse con un altro rettangolo e le collego con una freccia, credo di stare facendo dell'astrazione, in quanto non entro nei dettagli.
Scusate per le eventuali ripetizioni ma per me, come dite voi licelai "repetita iuvant".
mad_hhatter
30-03-2007, 14:34
beh, quello che intendevo io parte dalla progettazione di un software. L'astrazione mi serve per non entrare nei dettagli(tecnicismi) per poter essere capito anche da personale non tecnico.
Se un'auto la rappresento come un rettangolo ed idem, se una classe la rappresento come un rettangolo e la sua sottoclasse con un altro rettangolo e le collego con una freccia, credo di stare facendo dell'astrazione, in quanto non entro nei dettagli.
Scusate per le eventuali ripetizioni ma per me, come dite voi licelai "repetita iuvant".
si si, stai facendo astrazione, ci mancherebbe altro...
solo pensavo che PGI-Bis avesse in mente un'altra cosa (ogni tanto parto per la tangente, :D ): credevo che per lui quello che intendevi tu fosse data hiding e io cosi' ho pensato che, sempre per lui, astrazione fosse il processo di generalizzazione, cioe' l'opposto della derivazione di una classe a partire da una piu' generale.
In realta' per PGI-Bis astrazione e' un concetto molto piu' ampio: e' un processo mentale atto a rappresentare un'entita'. Semplicemente avevo frainteso il suop punto di vista ed ero partito per la tangente, scusami se ti ho fatto confusione...
In ogni caso, ricapitolando, il processo che hai descritto nell'ultimo post E' astrazione.
nel caso di PGI-Bis con molta probabilità si riferiva a quando ho detto che, astrazione era spiegare come funziona un meccanismo vvisto dall'esterno senza entrare nello specifico del suo funzionamento interno.
Come usare i metodi di una classe no scritta da me.
Credo si chiami data hiding ????
mad_hhatter
30-03-2007, 20:25
nel caso di PGI-Bis con molta probabilità si riferiva a quando ho detto che, astrazione era spiegare come funziona un meccanismo vvisto dall'esterno senza entrare nello specifico del suo funzionamento interno.
Come usare i metodi di una classe no scritta da me.
Credo si chiami data hiding ????
piu' correttamente si parla di incapsulamento, di cui il data hiding e' un aspetto particolare. comunque si', si tratta di quello
quando si parla di chiusura transitiva tra moduli(package) si intende una cosa del genere ?
esempio:
ho l'insieme R = { (m1,m2) , (m2,m1) , (m2,m2) , (m3,m2) }
se voglio fare la chiusura transitiva di questo insieme considero R una relazione transitiva e aggiungo all'insieme le coppie che posso dedurre grazie a questa proprietà:
ho (m1,m2) e (m2,m1) -> devo avere anche (m1,m1)
ho (m3,m2) e (m2,m1) -> devo avere anche (m3,m1)
per cui ottengo
chius. trans. di R = { (m1,m1) , (m1,m2) , (m2,m1) , (m2,m2) , (m3,m1) , (m3,m2) }
mad_hhatter
31-03-2007, 11:13
quando si parla di chiusura transitiva tra moduli(package) si intende una cosa del genere ?
esempio:
ho l'insieme R = { (m1,m2) , (m2,m1) , (m2,m2) , (m3,m2) }
se voglio fare la chiusura transitiva di questo insieme considero R una relazione transitiva e aggiungo all'insieme le coppie che posso dedurre grazie a questa proprietà:
ho (m1,m2) e (m2,m1) -> devo avere anche (m1,m1)
ho (m3,m2) e (m2,m1) -> devo avere anche (m3,m1)
per cui ottengo
chius. trans. di R = { (m1,m1) , (m1,m2) , (m2,m1) , (m2,m2) , (m3,m1) , (m3,m2) }
stando ai miei ricordi di informatica teorica mi pare sia corretto
rimanendo in tema di richiamo di moduli, un DAG(grafo aciclico) è tale sse non esistono situazione del tipo: il modulo A chiama il modulo B che a sua volta richiama il modulo A ?
Può esistere una chiamata transitiva ma non un ciclo in quanto potrebbe generare un dedlock ?
Non ho ancora seguito algoritmi :stordita:
Scusa il pasticcio di termini.
mad_hhatter
31-03-2007, 12:57
rimanendo in tema di richiamo di moduli, un DAG(grafo aciclico) è tale sse non esistono situazione del tipo: il modulo A chiama il modulo B che a sua volta richiama il modulo A ?
si
Può esistere una chiamata transitiva ma non un ciclo in quanto potrebbe generare un dedlock ?
temo di non aver capito
scusa ma per la seconda domanda mi sono espresso male :stordita:
Intendevo che se è la ciclicità la responsabile dei deadlock e se le chiamate transitive non sono definite cicliche: A che per arrivare a C deve passare per B ad esempio
mad_hhatter
31-03-2007, 13:35
scusa ma per la seconda domanda mi sono espresso male :stordita:
Intendevo che se è la ciclicità la responsabile dei deadlock e se le chiamate transitive non sono definite cicliche: A che per arrivare a C deve passare per B ad esempio
mi dispiace, temo di non saperti aiutare... o forse continuo a nn capire... tieni presente che ho fatto ing info, forse ho una formazione differente per cui certi termini mi sfuggono
sono io che mi sto esprimendo male, in quanto credo di avere ancora un pò di confusione; il tempo di meditarci un pò sopra e chiarirò quanto chiedevo: magari scopro che non aveva alcun senso :stordita:
un dubbione, se leggete prima qua http://www.itis.mn.it/inform/oop/scheda.htm#tre circa l'information hiding.
Ma il concetto di interfaccia che abbiamo discusso nei precedenti post cosa ha a che vedere con il concetto espresso al link ? :confused:
Prima immaginavo interfaccia una sorta di ponte tra due classi, mentre al link si parla di come va usata una classe e cioè, specificare documentando come va usata senza spiegare come funziona internamente :mbe:
Stesso termine ma concetti differenti ?
Quando dissi che un conto è l'interfaccia Java e un conto l'interfaccia di wikipedia, intendevo proprio quello che ho detto :D.
L'interfaccia di wikipedia è la stessa della pagina che hai collegato. Data una classe, prendi tutto quello che è public. Considera tutti gli invarianti esplicitamente o implicitamente correlati a quei "public" e hai in mano l'interfaccia. Diciamo "interfaccia nel senso di quello che permette di interfacciarsi"? In italiano fa un po' schifo ma penso renda l'idea. Probabilmente sarebbe più suggestivo parlare di "contratto". Un accordo tra la classe e chi la vuole usare: con me puoi fare questo questo e quest'altro. Sa un po' di sado-maso ma in fondo è così.
L'interfaccia Java, nel senso di tipo dichiarato tramite la parola chiave interface, è un mostro diverso e fa storia a sè. Fa storia a sè perchè Java ha sia le interfacce che le classi. Non dovrebbe avere le classi ma ce le ha. Come si dice, nessuno è perfetto... :D.
mad_hhatter
01-04-2007, 14:42
Quando dissi che un conto è l'interfaccia Java e un conto l'interfaccia di wikipedia, intendevo proprio quello che ho detto :D.
L'interfaccia di wikipedia è la stessa della pagina che hai collegato. Data una classe, prendi tutto quello che è public. Considera tutti gli invarianti esplicitamente o implicitamente correlati a quei "public" e hai in mano l'interfaccia. Diciamo "interfaccia nel senso di quello che permette di interfacciarsi"? In italiano fa un po' schifo ma penso renda l'idea. Probabilmente sarebbe più suggestivo parlare di "contratto". Un accordo tra la classe e chi la vuole usare: con me puoi fare questo questo e quest'altro. Sa un po' di sado-maso ma in fondo è così.
L'interfaccia Java, nel senso di tipo dichiarato tramite la parola chiave interface, è un mostro diverso e fa storia a sè. Fa storia a sè perchè Java ha sia le interfacce che le classi. Non dovrebbe avere le classi ma ce le ha. Come si dice, nessuno è perfetto... :D.
saranno tecnicamente cose diverse, ma concettualmente hanno lo stesso fine: definire appunto un contratto di utilizzo... perche' dici che sono due cose cosi' distinte?
e perche' java non dovrebbe avere le classi?
L'interfaccia Java, nel senso di tipo dichiarato tramite la parola chiave interface, è un mostro diverso e fa storia a sè. Fa storia a sè perchè Java ha sia le interfacce che le classi. Non dovrebbe avere le classi ma ce le ha. Come si dice, nessuno è perfetto... :D.
ed è quello che ho pensato io. Sul mio libro di ingegneria del software si parla di moduli che altro non sono che classi. Chi usa un modulo diviene client di quel modulo e per usare tale modulo, che diviene server, questo mette a disposizione una bella interfaccia.
Ad esempio: supponiamo che un modulo(classe) abbia definito i metodi INSERT, DELETE, PRINT.
Solo tali comandi che sono poi l'interfaccia del client verso il server sono noti: ma come è strutturao internamente il modulo non è dato di saperlo.
L'interfaccia vista in questi termini e come la avevo interpretata prima e cioè, ponte tra due classi, non mi fa vedere punti in comune.
:muro:
scusate: mai sentiti i termini relazione USES e relazione IS_COMPONENT_OF ?
mad_hhatter
01-04-2007, 15:07
ed è quello che ho pensato io. Sul mio libro di ingegneria del software si parla di moduli che altro non sono che classi. Chi usa un modulo diviene client di quel modulo e per usare tale modulo che diviene il server, mette a disposizione una bella interfaccia.
Ad esempio: supponiamo che un modulo(classe) abbia definito i metodi INSERT, DELETE, PRINT.
Solo tali comandi che sono poi l'interfaccia del client verso il server sono noti: ma come è strutturao internamente il modulo non è dato di saperlo.
L'interfaccia vista in questi termini e come la avevo interpretata prima e cioè, ponte tra due classi, non mi fa vedere punti in comune.
:muro:
scusate: mai sentiti i termini relazione USES e relazione IS_COMPONENT_OF ?
veramente e' il server che espone un'interfaccia, in quanto utilizzato.
l'entita' java chiamata interface non e' altro che un modo per dire che un gruppo di classi espongono ALMENO un certo tipo di interfaccia... come vedi il fine e' lo stesso concettualemnte.
li ho sentiti, perche'?
veramente e' il server che espone un'interfaccia, in quanto utilizzato.
magari l'ho scritto male ma è quello che intendevo pure io :stordita:
Le relazioni citate sono prodotti di "Design patterns: elements of reusable object-oriented", di Gamma e altri. Un libro che dice "abbiamo visto tanto codice e in quel codice ci pare che questi siano gli elementi più ricorrenti" e che è stato letto come "questo è l'orientamento agli oggetti". Immagino che la bizzarria salti agli occhi.
Comunque è quello l'orientamento agli oggetti che devi sapere. Che poi non funzioni è irrilevante :mad:
Una volta chiesero a Ken Arnold, uno dei progettisti di Java: "se potesse tornare indietro, come rifarebbe Java". E lui disse: "eliminerei le classi". Essendo Java un linguaggio "class-based" la cosa suscitò un qualche scalpore :D. Per me ha ragione da vendere.
Il problema nasce dalla definizione di classe. All'inizio era: una classe è l'insieme delle caratteristiche essenziali di uno o più oggetti. Poi si è scoperto che l'essenzialità è indefinibile e si è passati a: una classe è l'insieme delle caratteristiche rilevanti di uno o più oggetti. In entrambi i casi caratteristica è una proprietà o un comportamento osservabile.
Tutto ciò che non è osservabile non è caratteristica. Si tratta di una considerazione elementare: se non vedo, non ci credo.
In Java esistono due strumenti atti a rappresentare una classe, intesa come categoria di oggetti per l'orientamento agli oggetti. Posso esprimere una collezione di proprietà o comportamenti osservabili:
1. con un'interfaccia
2. con una classe
Perchè due? Storia dell'orientamento agli oggetti. Quello che noi chiamiamo ereditarietà è un fenomeno diviso in due correnti. Scandinava e Americana (K. Nygaard e O. J. Dhal). La corrente Scandinava chiama l'ereditarietà Americana estensione. L'Americana non distingue.
Per la Scandinava, ciò che una sottoclasse deve riceve da una superclasse affinchè si abbia ereditarietà è ristretto a tutto e solo ciò che una classe può per definizione possedere: un insieme di proprietà osservabili. Una sottoclasse eredita il fatto che certe proprietà o comportamenti esistono e null'altro.
Per l'Americana, una sottoclasse riceve sia la dichiarazione delle proprietà o comportamenti sia la definizione di quelle proprietà e di quei comportamenti contenuti nella superclasse.
Il secondo fenomeno fa, dal punto di vista teorico, acqua da tutte le parti. Esiste un diverso concetto di ereditarietà ma non un diverso concetto di classe. E l'ereditarietà coerente con il concetto di classe è quella scandinava: una classe è un insieme di dichiarazioni, non di dichiarazioni e definizioni. Non può tramandare alle figlie quello che non ha. Per questo la corrente Scandinava designa con un nome diverso, estensione, l'ereditarietà americana.
Pazzi americani? No. Pratici. Se posso trasferire da una classe all'altra anche la definizione di una caratteristica (e non solo la sua dichiarazione) allora posso anche evitare di riscrivere ogni volta le stesse cose nelle sottoclassi. Meno scrivo, meno sbaglio. E' una delle poche certezze della programmazione :D.
Il prezzo teorico che paga Java in questi termini è tuttavia altissimo. La differenza tra classe e oggetto sta in ciò che un oggetto definisce l'insieme di proprietà dichiarate dalla sua classe.
Cosa in Java consente di dichiarare senza definire? L'interfaccia. Si adatta veramene benissimo al concetto di classe dell'orientamento agli oggetti ed è di un'elenganza meravigliosa se confrontata, ad esempio, alla classe base astratta di C++. Cosa c'è di più mirabile di:
public interface Cane {
void abbaia();
}
Pura dichiarazione, pura classe (in tutti i sensi :D). Ed è facilissimo da spiegare. Cosa eredita un'interfaccia figlia da un'interfaccia madre? La sola cosa che può ereditare perchè è la sola che una "classe" può contenere: la dichiarazione di un insieme di comportamenti.
Volendo restare coerente con il modello "scandinavo" dell'ereditarietà, Java avrebbe dovuto avere al posto del tipo class il tipo object: un class senza estensione. Piglia la categoria-interfaccia, la definisci nell'oggetto e, se te ne serve più d'uno, crei cloni di quell'oggetto.
Includere la definizione di un comportamento nella classe non consente, ovviamente, di usare questo elemento come distinguo tra classe e oggetto. Correntemente, in effetti, il tratto distintivo è un altro. Oggetto è ciò che attualmente possiede uno dei valori potenziali secondo la sua definizione di classe. Il che è come minimo problematico.
Java usa l'estensione perchè non è un cesello con cui ricamare eleganti iniziali su tavolette di marmo. E' un barile di dinamite con cui scavi cento tonnellate di carbone al minuto. Questione di praticità. Passare dalle classi alle interfacce, dalle istanze ai singleton (eh sì, Gamma e altri: gli oggetti sono singleton e il prossimo libro è meglio che lo chiami "Pattern Oriented Patterns") è piuttosto scomodo :D.
Onde evitare che si pensi "ma guarda 'sto pazzo che s'inventa" ma anche, e soprattutto, per soddisfare ulteriori "curiosità", rimando a tre colonne dell'orientamento agli oggetti.
The Birth of Object Orientation: the Simula Languages; June, 2001, di O. J. Dhal
http://heim.ifi.uio.no/~olejohan/birth-of-oo.pdf
Object Oriented Programming in The Beta Programming Language, di K. Nygaard
www.daimi.au.dk/~beta/Books/betabook.pdf
The Early History Of Smalltalk, di Alan Kay
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
Fenomenale Kay quando dice (vado a memoria): "a quel tempo i linguaggi avevano nomi altisonanti come Thor, Odino e non combinavano niente. Decisi di chiamare il mio Smalltalk perchè sembrava inoffensivo e se fosse stato un flop non se ne sarebbe accorto nessuno".
Vorrei fare un piccolo OT per ringraziare PGI-Bis per la sua spiegazione della differenza tra classi e interfacce.
Sto muovendo i primi passi con StarBasic (orrore ;) ) e mi sono chiesto più volte che cosa significasse la frase "l'oggetto RowSet implementa (tra le altre) l'interfaccia XResultSet".
Anche se non sono dal lato di chi effettua l'analisi per definire il modello mi è di grosso aiuto per (iniziare a) capire "cosa" sto facendo.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.