View Full Version : Programmazione orientata agli ogg:interfacce ,implements, abstract e liste!!dove?
golf150cv
09-06-2006, 22:31
salve raga...
stò studiando programmazione orientata agli oggetti in java...
sono ad ingegneria informatica.....
devo dire che è un bel corso, ma adesso in poo ho alcuni problemini....
non riesco a capire in base a cosa dichairarae abstract, a fare implement, comparable, e perchè si fà, e a cosa serve la benedda interfaccia? e i metodi ricorsivi? a cosa diamine servono? come si struttura? tutto in un file? per i fatti suoi? le parentesi graffe nei metodi astratti vanno anche chiuse? in base a cosa dò il niome della classe?
quasli sono i metodi che devo ridefinire dell'interfaccia? e perchè?
se qualcuno è in grado di chiarirmi un pò le idde gli sarei davvero grato.....
oppure se conoscete qualche bel sito chiaro e limpido che spieghi il tutto
grazie saluti
Un consiglio: segui il corso con attenzione e mettiti a provare per conto tuo. Scoprirai le cose pian piano come succede con tutte le discipline.
Un buon libro interessante è quello che trovi su www.mokabyte.it
franksisca
10-06-2006, 12:06
stai facendo poo con pupo o con nigro???
se sei con pupo, mi spiace, è preparatissimo ma è un pacchista, ti consiglio, anche se oramai e tardi, di seguire nigro, per il resto, cosa dirti, sul mokabyte c'è tutto, ti posso consigliare anche un paio di libri, tipo "mattone dopo mattone" o i vari horstmann, altrimenti se vuoi, possiamo fare una bella discussione di spiegazione , dove ognuno mette la sua.....
tipo:
abstract
una classe si dice abstract quando ha almeno un metodo abstract
implements serve per implementare le interfaccie, ciò vuol dire che gli oggetti diventano anche del tipo dell'interfaccia, per esempioComparable [oppure comparetor;)]
serve per rendere un oggetto confrontabile con il metodo compareTo[o compare e basta];metodi ricorsivi sono un pò più rompiscatole, se non li capisci ora li capirai a algoritmi e strutture dati di Flesca, ma per farti un idea prova a fare la somma degli elementi di un vettore ricorsivamente, se hai problemi diccelonomi delle classi bhè, in questo caso tutto sta all'inventiva e all'identificazione. se parli di una scuola, e logico che avrai delle classi con nomi tipo Studente, Docente, Aula Materia, e che sicuramente non avrai classi col nome Giocatore, Master, CollegamentoDB.
Il nome lo metti e lo decidi tu!!!!
Se hai altri problemi, ti consiglio di chiedere qui, ci sonio m olti ragazzi in gamba.
golf150cv
10-06-2006, 13:44
ciao.. grazie per le risposte raga....
stò seguendo con nigro.. è davvero bravo e preparato, però non capisco a cosa serve l'interfaccia, qual'è lo scopo, perchè devo implementare e perche alcuni metodi mi conviene farli abstract ecc.....
non riesco ad avere un filo logico!
tu studi informatica a cosenza?
grazie saluti
Ciao,
l'utilizzo delle interfacce è fondamentale perchè specifica che una classe "implementa" determinate operazioni quelle appunto specificate dalle interfacce.
Questo permette di slegare il codice dalle implementazioni concrete che si utilizzano. Inoltre il java permette la sola ereditarietà singola, l'utilizzo delle interfacce ti permette di modellare una ereditarietà di interfaccia multipla.
Un artico9lo, forse un pò complesso però, che ti può aiutare a chiarirti lo puoi trovare su
eptacom (http://www.eptacom.net) cerca su pubblicazioni l'articolo "oggetti ed interfacce"
Per fare un esempio, le collection in Java.
Supponi di avere un metodo che funziona su un insieme. Accetterà come parametro un Set. Però gli potrai passare come parametro di volta in volta un TreeSet o un HashSet a seconda delle necessità, o se domani progetti il PippoSet e gli fai "implementare " l'interfaccia Set, ecco che lo puoi usare subito e il tuo metodo non necessiterà di modifiche (almeno se è progettato bene).
ciao.
In Java le interfacce esprimono il concetto di relazione tra due oggetti.
Definisco relazione il comune possesso da parte di almeno due oggetti di una caratteristica (nel senso più generico immaginabile) accomunante.
Una curiosità: Ken Arnold, uno dei progettisti del linguaggio, ad una conferenza una volta disse che se avesse potuto reinventare Java avrebbe tolto le classi.
Il linguaggio Java è confuso dal fatto che anche le classi, primariamente deputate alla definizione di un oggetto (e non di una categoria di oggetti, come si sente dire ogni tanto) possono esprimere un particolare relazione tra oggetti, la relazione gerarchica altrimenti nota col nomignolo di is-a.
La relazione gerarchica attiene a caratteristiche essenziali ma qui sappiamo che la teoria classica è priva di un criterio per distinguere quali proprietà siano essenziali e quali non lo siano dal che si ricava che la gerarchia è nelle mani dell'arbitrio di chi la crei (il che la rende ingiustificabile).
Il problema non è quindi quando usi l'interfaccia Java ma quando, in un sistema orientato agli oggetti, individui una relazione. Una volta che tu l'abbia individuata dovrai dichiarare un'interfaccia.
Dal principio di identità ricaviamo che un oggetto non può essere a conoscenza delle caratteristiche di un altro oggetto: se, infatti, tali caratteristiche dovessero mutare, muterebbe anche di necessità l'oggetto a cui tali caratteri siano noti al che questo secondo oggetto non sarebbe più identico solo a sè stesso ma identico a sè più qualcos'altro (e dunque oggetto sarebbe la somma dei due pseudo-oggetti).
Se un oggetto non può conoscere un altro oggetto allora non gli resta che essere al corrente di una relazione che, guarda caso, non dipende dalla definizione di questo o quell'oggetto.
La necessità di esprimere una relazione in un programma orientato agli oggetti sorge quindi quando esistano almeno tre oggetti, due dei quali possiedano una caratteristica accomunante ed il terzo dei quali necessiti di tale caratteristica per la sua definizione.
Nel caso scolastico del proiettore di geometrie hai un oggetto che disegna delle figure su una superficie, un rettangolo, un cerchio e un triangolo.
Qui il proiettore non disegna affatto il mitologico Shape, genitore di rettangolo, cerchio e triangolo: il proiettore vuole disegnare cerchio, rettangolo e triangolo.
Non può farlo perchè se lo facesse la sua definizione diventerebbe dipendente dalla definizione di rettangolo, cerchio e triangolo. Tale dipendenze spezzerebbe l'autonomia del proiettore e il risultato sarebbe non un sistema composto di Proiettore, Cerchio, Rettangolo e Triangolo ma di un ProiettoreCerchioRettangoloTriangolo, sebbene eventualmente (e maldestramente) definiti in quattro classi Java.
Per risolvere l'arcano basta domandarsi quale caratteristica utile alla definizione di Proiettore sia posseduta da Cerchio, Rettangolo e Triangolo. Non un'ipotetica qualità essenziale o una caratteristica potenziale di categorie a cui dovremmo pensare se il sistema dovesse evolversi in chi sa cosa. Solo quello che, nel fenomeno che stiamo osservando e riproducendo, serve a Proiettore.
Una volta individuata, esprimi in Java questa caratteristica (o queste caratteristiche, se siano più d'una) usando un'interfaccia. Nel nostro caso di scuola potremmo avere:
public interface Drawable {
void draw(Graphics g);
}
public class Renderer {
public void draw(Graphics g, Drawable...d) {...omissis}
}
public class Rectangle implements Drawable {
public void draw(Graphics g) {
...disegna questo rettangolo su g
}
}
public class Triangle implements Drawable...
eccetera. Dico potremmo perchè l'individuazione del carattere accomunante dipende interamente dal sistema di riferimento cioè dal risultato dell'umana osservazione del fenomeno che si intende riprodurre.
Come ogni interfaccia, anche Comparable esprime una relazione, un tratto comune a due o più oggetti utile alla definizione di un terzo oggetto. In quel caso il tratto comune è la capacità di essere confrontato con un altro oggetto. O quasi. Leggendo il codice e stando alla caratteristiche di Java dovremmo dire che Comparable è una relazione di comparabilità tra oggetti altrimenti correlati ma questa è un'altra (lunga) storia.
Puoi fare un intero programma usando un solo file cioè definendo un solo oggetto? Certamente sì. Basta che tu sappia che stai definendo un solo oggetto. Nota però che se il sistema di riferimento ti pare composto di più di un oggetto e tu hai scritto una sola classe, c'è qualcosa che non va: quello che hai rappresentato nel codice non corrisponde a quello che hai osservato. La mancata corrispondenza ti fa perdere il vantaggio dell'orientamento agli oggetti perchè prima o poi ti troverai nella necessità di esprimere almeno una parte del sistema di riferimento secondo una prospettiva diversa da quella assunta quando l'hai osservato.
Puoi fare un intero programma usando un solo file cioè definendo un solo oggetto? Certamente sì. Basta che tu sappia che stai definendo un solo oggetto. Nota però che se il sistema di riferimento ti pare composto di più di un oggetto e tu hai scritto una sola classe, c'è qualcosa che non va: quello che hai rappresentato nel codice non corrisponde a quello che hai osservato. La mancata corrispondenza ti fa perdere il vantaggio dell'orientamento agli oggetti perchè prima o poi ti troverai nella necessità di esprimere almeno una parte del sistema di riferimento secondo una prospettiva diversa da quella assunta quando l'hai osservato.
E' molto interessante questo discorso sull'"osservazione" e la modellazione di cio' che si e' osservato.
Un errore molto comune che si commette quando si inizia a programmare OOP e' fare larghissimo uso del concetto di Inheritance (una classe che deriva da un'altra), che modella la relazione che PGI ha chiamato "is-a".
Spesso la colpa e' di chi insegna o del metodo di insegnamento dell'OOP.
Il concetto di derivazione fra classi e' estramemente potente, e come tale difficile da controllare: abusarne porta molto facilmente a creare enormi gerarchie di classi che si rivelano ingestibili. Lo strumento dell'OOP finisce non per facilitare la vita, ma per renderla piu' complessa.
Per altro la relazione "is a" appare molto meno spesso di quanto si pensi nei problemi osservati. Ad esempio, una macchina non "e' un" motore, una macchina "e' composta da un" motore, e da altri pezzi. Nonostante questo spesso si modella questa osservazione derivano la classe Macchina dalla classe Motore. Errore. Un oggeo della classe Macchina contiene un oggetto della classe Motore.
Il consiglio e' di guardare con sospetto tutte le volte che senti il bisogno di ereditare una classe da un'altra e porti queste domande:
- Sto modellando una vera relazione "is a"? La classe A "e' un" B?
- Posso usare la classe A ovunque la classe B puo' essere usata? (questo si chiama principio di sostituzione)
- La classe A onora tutti i contratti della classe B?
Se una di queste domande ti da' risposta negativa, allora non derivare e preferisci fare composizione fra classi. Non usare mai la derivazione come uno strumento per condividere codice comune fra due classi. Puoi scrivere interi programmi perfettamente OOP senza derivare una sola classe.
cdimauro
14-06-2006, 08:49
Gli ultimi due messaggi sono delle autentiche perle. Il thread meriterebbe d'esser messo in rilievo. ;)
didatticamente parlando, sarebbe molto comodo un linguaggio OOP senza l'ereditarieta(di classi, di interfaccie la lascerei), un po come si fa usare schema o altri linguaggi funzionali per spingere gli studenti a guardare la ricorsione.
In effetti ho fatto anche io lo stesso errore all'inizio, considerando l'ereditarietà fra classi come la cosa piu importante dell'OOP, probabilmente perchè è piu esplicita nei linguaggi rispetto alla composizione...
solo ultimamente riesco ad applicare il "prefer composition over inheritence", sopratutto grazie a diamonds e al gof :)
confermo, grazie per le utili precisazioni.
Gli ultimi due messaggi sono delle autentiche perle. Il thread meriterebbe d'esser messo in rilievo. ;)
Allora siam messi proprio bene :D. A me pare che io e Fek abbiamo espresso due punti di vista assolutamente incompatibili! Forse mi sono espresso male io. Mah, misteri dell'informatica!.
cdimauro
14-06-2006, 11:59
Veramente a me sembra che fek, anzi, avalli proprio quello che hai scritto. Effettuando poi delle precisazioni.
A questo punto mi sorge il dubbio potrei essere io quello che non ha capito niente. :p
jappilas
14-06-2006, 13:02
Allora siam messi proprio bene :D. A me pare che io e Fek abbiamo espresso due punti di vista assolutamente incompatibili! Forse mi sono espresso male io. Mah, misteri dell'informatica!.
a me sembra che abbiate esposto due aspetti complementari :)
solo ultimamente riesco ad applicare il "prefer composition over inheritence", sopratutto grazie a diamonds e al gof :)
allora vuol dire che diamonds è riuscito nel suo intento didattico :)
jappilas
14-06-2006, 13:07
In effetti ho fatto anche io lo stesso errore all'inizio, considerando l'ereditarietà fra classi come la cosa piu importante dell'OOP, probabilmente perchè è piu esplicita nei linguaggi rispetto alla composizione...
e pensa che a me è stato inculcato che l' aspetto basilare e fondante della OOP, nonchè l' aspetto più utile della progettazione di programmi fosse la data and code encapulation abbinata alla enforced visibility (cioè il fatto di integrare nella classe i dati con il codice che li maneggia, e soprattutto applicare una policy in modo uniforme per mascherare o rendere pubblici i membri di una classe)
... nemmeno la composition in sè ... :D
e pensa che a me è stato inculcato che l' aspetto basilare e fondante della OOP, nonchè l' aspetto più utile della progettazione di programmi fosse la data and code encapulation abbinata alla enforced visibility (cioè il fatto di integrare nella classe i dati con il codice che li maneggia, e soprattutto applicare una policy in modo uniforme per mascherare o rendere pubblici i membri di una classe)
... nemmeno la composition in sè ... :D
beh si, i fondamenti classici sono l'incapsulamento, ereditarietà e il poliformismo.
jappilas
14-06-2006, 14:14
beh si, i fondamenti classici sono l'incapsulamento, ereditarietà e il poliformismo.
lo so ... ma per la tizia che c' insegnava fondamenti di informatica II, apparentemente la programmazione a oggetti è nata solo o principalmente per, o comunque intorno al concetto di, porre dati e funzioni sotto policy di visibilità public/private ... cosa che a me sembra più una conseguenza della concezione di un determinato linguaggio OO, che una causa fondante di tutto il paradigma ad oggetti... :stordita:
Con tutta probabilità, causa la foga passionale, mi sono espresso in modo non chiaro. Mettiamola così.
Senza alcuna vena polemica e anzi, con il proposito di avviare una sana e onesta discussione, delle tre domande fondamentali proposte da fek, io ritengo la prima più un motto che una questione, e la terza uguale alla seconda.
Sulla prima credo si possa convenire che chiedersi se io stia realizzando una "vera" relazione is-a non sia proprio determinante per risolvere il dubbio se A e B siano in relazione is-a.
E sulla seconda potremmo iniziare a rotolarci nella mota ora per saltarne fuori solo a barbe bianche :D.
Quand'è che posso usare l'oggetto A ovunque sia presente l'oggetto B? La risposta è sempre o mai.
Sempre se A e B siano in relazione cioè possiedano una qualsiasi caratteristica in comune e tale caratteristica sia necessaria alla definizione di C, per come A B e C risultano nel sistema di riferimento, perchè per la definizione di oggetto è sempre possibile eliminare un oggetto dal sistema e quindi è anche possibile rimpiazzare un oggetto con un altro. Funzionalmente, cioè agli occhi di C, la sostituzione di A con B è irrilevante perchè nè A nè B sono noti a C. C può essere al corrente della sola relazione esistente tra A e B, non della definizione nè dell'esistenza di A o B.
Nel campo della composizione io mi muoverei poi con i proverbiali piedi di piombo. Una macchina è un composto di motore e carrozzeria in due sensi. O macchina è oggetto e motore e carrozzeria sono parti della sua definizione e allora tra macchina motore e carrozzeria non c'è alcuna relazione, salvo ammettere che l'identità sia un tipo particolare di relazione che un oggetto ha con sè stesso.
Oppure macchina motore e carrozzeria sono tre oggetti e allora macchina non può essere composta di motore e carrozzeria ma può essere al corrente di una relazione che intercorre tra motore e carrozzeria e usare tale relazione: ad esempio, motore e carrozzeria potrebbero essere correlati da una qualche caratteristiche simbolicamente espressa in ComponentePerAutomobile.
E qui, però, manca ancora la relazione tra Automobile e Motore e Automobile e Carrozzeria: c'è tra motore e carrozzeria ed è ritenuta necessaria per la definizione di Automobile ma non c'è tra Automobile e Motore.
Mi seguite o vi sembro del tutto pazzo? :D.
Cioè, siamo sicuri che questa "composizione" sia veramente una relazione tra oggetti o, meglio, che si possa dare una relazione con un elemento tipico tale da dotarla di autonomia concettuale rispetto ad un qualsiasi altro tipo di relazione? E se sì, quale sarebbe questo elemento tipico?
Sulla prima credo si possa convenire che chiedersi se io stia realizzando una "vera" relazione is-a non sia proprio determinante per risolvere il dubbio se A e B siano in relazione is-a.
La tua affermazione e' tautologica :)
Per risolvere il dubbito se A e B sono in relazione is-a, devo ovviamente domadarmi se sono in relazione is-a.
Io ho scritto una cosa leggermente diversa, probabilmente non sono stato chiaro: per modellare la relazione fra due oggetti con lo strumento dell'ereditarieta' devo domandarmi se questi due oggetti sono in relazione is-a o no.
Esempio del martello che mi piace tanto :D
Per usare un martello (l'ereditarieta' che modella una relazione is-a) devo domandarmi se voglio piantare un chiodo. Se voglio limare (relazione di composizione), non uso un martello, ma la lima. Lo strumento giusto per il compito giusto.
E sulla seconda potremmo iniziare a rotolarci nella mota ora per saltarne fuori solo a barbe bianche :D.
La seconda e' facile da definire univocamente: posso usare l'oggetto A al posto dell'oggetto B quando l'oggetto A onora tutti i contratti di B (ovvero, "e' un B") e inoltre onorera' altri contratti, oppure modifichera' alcuni contratti di B in maniera "compatibile", ovvero in maniera che il comportamento osservabile dopo la sostituzione sia il medesimo.
Oppure macchina motore e carrozzeria sono tre oggetti e allora macchina non può essere composta di motore e carrozzeria ma può essere al corrente di una relazione che intercorre tra motore e carrozzeria e usare tale relazione: ad esempio, motore e carrozzeria potrebbero essere correlati da una qualche caratteristiche simbolicamente espressa in ComponentePerAutomobile.
Qui c'e' proprio un errore: un oggetto puo' essere tranquillamente composto da altri oggetti. La relazione fra l'oggetto e gli oggetti di cui e' composto e', per l'appunto, una relazione di composizione.
Infatti UML fornisce gli strumenti per descrivere una relazione di composizione:
Composition Relationships
Each instance of typeCircle
seems to contain an instance of type Point. This is a relationship known as
composition. It can be depicted in UML using a class relationship. Figure 3 shows the composition relationship.
Da un piccolo manualetto di UML:
http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf
Al solito iniziamo a tirarci l'un l'altro addosso petizioni di principio :D.
Non posso affermare che siccome UML prevede la relazione di composizione allora la relazione di composizione è una relazione OO.
UML è un linguaggio che serve per condividere tra due persone un modello di sistema orientato agli oggetti. Fornisce quanto è necessario a rappresentare un sistema di riferimento (a farne cioè un modello di sistema). Non spiega nè ha mai preteso di farlo l'orientamento agli oggetti.
E' come usare un cacciavite per un omicidio: si può fare ma la funzione è un tantino travisata :D.
Per risolvere il dubbio se A e B siano in relazione is-a non devo domandarmi se A e B siano in relazione is-a: quello è il dubbio che voglio risolvere.
Per sapere se A e B siano in relazione is-a devo chiedermi se A e B siano in relazione is-a? Bene, A e B sono in relazione is-a? Be', devo chiedermi se A e B siano in relazione is-a. A e B sono in relazione is-a? Be'... e divenni vecchio :D.
Sul martello, avevo frainteso quanto hai scritto. Non concordo sui presupposti (non sia mai :D ) ma il discorso fila.
Un oggetto non può essere composto di altri oggetti: perderebbe la sua autonomia. Tieni conto, però, che io vedo il contratto come una relazione tra più oggetti. Cioè se dico, in Java:
public class Macchina {
private Motore motore;
private Carrozzeria carrozzeria;
...eccetera
}
qui, assumendo che Motore e Carrozzeria siano tipi class, essi valgono non come definizioni di oggetti ma come definizioni di relazioni tra oggetti, cioè per il fatto che possono (e dovrebbero nel sistema di riferimento, altrimenti la cosa andrebbe espressa in modo diverso) esistere 3 diversi motori tutti quanti correlati dal possesso di quelle caratteristiche accomunanti definite nella classe (relazione) Motore.java.
In Java "class" è un jolly: definisce un oggetto e dichiara una relazione tra più oggetti (tutti quelli che extends quella classe sono correlati).
Al solito iniziamo a tirarci l'un l'altro addosso petizioni di principio :D.
Altrimenti dov'e' il divertimento? :D
Non posso affermare che siccome UML prevede la relazione di composizione allora la relazione di composizione è una relazione OO.
Il fatto che UML preveda la relazione, e' comunque un forte indizio, non credi?
Per risolvere il dubbio se A e B siano in relazione is-a non devo domandarmi se A e B siano in relazione is-a: quello è il dubbio che voglio risolvere.
Uh? Mi sono perso.
Un oggetto non può essere composto di altri oggetti: perderebbe la sua autonomia. Tieni conto, però, che io vedo il contratto come una relazione tra più oggetti.
E che problema c'e' se un oggetto non e' autonomo? Mica smettere di essere un oggetto. D'altronde, slegandoci dal linguaggio che e' solo una particolare implementazione, tutti gli oggetti sono composizione di altri oggetti, fino ad oggetti molto semplici che sono composti da "oggetti base" come gli interi.
In Java i numeri non sono oggetti (in realta' comunque lo sono) per una questione solo di efficienza, non logica.
qui, assumendo che Motore e Carrozzeria siano tipi class, essi valgono non come definizioni di oggetti ma come definizioni di relazioni tra oggetti, cioè per il fatto che possono (e dovrebbero nel sistema di riferimento, altrimenti la cosa andrebbe espressa in modo diverso) esistere 3 diversi motori tutti quanti correlati dal possesso di quelle caratteristiche accomunanti definite nella classe (relazione) Motore.java.
Invece essi valgono come definizione dell'oggetto Macchina come composizione di due Motore e Carrozzeria. Inoltre, la Macchina e' in relazione di composizione con gli oggetti Motore e Carrozzeria. Il che logicamente fila: una Macchina e' una collezione di di Motore, Carrozzeria e altri oggetti. Un parallelo naturale con il dominio del problema.
In Java "class" è un jolly: definisce un oggetto e dichiara una relazione tra più oggetti (tutti quelli che extends quella classe sono correlati).
E inoltre definisce una relazione di composizione con tutti gli oggetti della quali la casse e' composta. Non capisco perche' reputi la relazione di composizione come una relazione di serie B rispetto alla relazione di ereditarieta', quando, di nuovo, UML le dedica anche una sua descrizione specifica.
Inoltre, Design Pattern definisce moltissimi pattern come nient'altro che astrazioni su relazioni di composizione.
E che problema c'e' se un oggetto non e' autonomo? Mica smettere di essere un oggetto.
Di solito non quoto ma abbiamo trovato l'arca della divergenza (che quella dell'alleanze gli fa un baffo gli fa).
Se ritieni possibile che un oggetto sia tale pur non essendo autonomo allora è possibile che esista una categoria "relazione di composizione".
Per me tuttavia l'intera costruzione dell'orientamento agli oggetti non può che reggersi sul principio di identità o, meglio, sul rilievo che la condizione necessaria e sufficiente affinchè un elemento del sistema sia umanamente percepito come tale è che esso sia identico solo a sè stesso.
Il che richiede anche che sia autonomo cioè che la sua definizione sia autonoma rispetto alla definizione di un altro oggetto, contratto incluso se per contratto intendiamo, la dico a spanne, l'insieme di attributi e comportamenti pubblici di cui un oggetto dichiari il possesso a prescindere dall'appartenenza ad un certa categoria.
Gnè-Gnè, alla fine avevo ragione: eravamo su posizioni inconciliabili :D.
Di solito non quoto ma abbiamo trovato l'arca della divergenza (che quella dell'alleanze gli fa un baffo gli fa).
Se ritieni possibile che un oggetto sia tale pur non essendo autonomo allora è possibile che esista una categoria "relazione di composizione".
Assolutamente si', un oggetto e' tale pur non essendo autonomo, perche' nessun oggetto e' autonomo.
class A
{
int x;
}
A e' autonomo? No, dipende dall'oggetto x :)
Infatti e' in relazione di composizione con l'oggetto x, che e' un intero, ma sempre un oggetto.
Per me tuttavia l'intera costruzione dell'orientamento agli oggetti non può che reggersi sul principio di identità o, meglio, sul rilievo che la condizione necessaria e sufficiente affinchè un elemento del sistema sia umanamente percepito come tale è che esso sia identico solo a sè stesso.
Il che richiede anche che sia autonomo cioè che la sua definizione sia autonoma rispetto alla definizione di un altro oggetto, contratto incluso se per contratto intendiamo, la dico a spanne, l'insieme di attributi e comportamenti pubblici di cui un oggetto dichiari il possesso a prescindere dall'appartenenza ad un certa categoria.
Secondo me qui stai commettendo un errore perche' l'identita' di un oggetto non dipende dalla sua autonomia. Un oggetto istanza della classe Macchina e' perfettamente identico a se' stesso e a nessun altro. E non e' autonomo nel suo funzionamento perche' necessita' di collaborare in una relazione di composizione con gli oggetti Motore e Carrozzeria e magari con un oggetto intero Velocita'.
A mio avviso stai sbagliando proprio la definizione di OOP che, per dirla come la Gang Of Four, e' la descrizione delle relazioni fra gli oggetti che compongono il sistema.
Gnè-Gnè, alla fine avevo ragione: eravamo su posizioni inconciliabili :D.
E vabbe', ma ho ragione io :P
Booch e soci di orientamento agli oggetti non hanno mai capito una fava.
E se int non fosse un oggetto?
Supponi che int sia la relazione che intercorre tra tutti gli interi. Allora l'oggetto qui definito:
class Pippo {
private int x;
public void setX(int value) { x = value; }
public int getX() { return value; }
}
non sarebbe forse autonomo? E' "composto"? Non di un altro oggetto (sempre se int fosse un'ipotetica relazione). Usa una relazione che intercorre tra altri oggetti, l'ipotetico int.
D'altronde se accetti l'idea che oggetto sia un che di identico solo a sè stesso allora necessariamente, di necessità logica, devi anche dire che ogni oggetto è per definizione autonomo. Se non lo fosse, infatti, esso subirebbe delle mutazioni a seguito del cambiamento di definizione di un altro oggetto: a seguito della mutazione l'oggetto non sarebbe più identico a quello che era prima. Avremmo quindi un oggetto di cui si è predicata l'identità con sè stesso salvo il fatto che ad un certo punto è cambiato senza che la sua definizione sia stata minimamente toccata.
L'alternativa è dire che non tutte le caratteristiche di un oggetto contribuiscono a definirne l'identità: alcune possono mutare e nonostante questo l'oggetto è comunque identico a sè stesso.
Ma questa non è informatica, è poesia o cinema o teatro, perchè l'unica definizione verificabile di caratteristica essenziale è "tutte quelle che l'osservatore usa per descrivere l'oggetto".
So che suona strano, non è che io mi sia formato sui libri che vendono nella galassia di Zumpappà: ho letto quelli che abbiam letto tutti. E saltano fuori anche programmi dai sorgenti molto strani :D. Ma sono coerenti con un'idea che può essere espressa e spiegata dall'inizio alla fine secondo una logica umanamente comprensibile (cioè una logica ce l'hanno).
Non che io abbia quadrato il cerchio. Almeno un problema ce l'ho: il problema del giorno zero. Qualcuno gli oggetti deve crearli. Una volta che siano stati creati tutto fila liscio come l'olio, perchè sono "passati" agli altri in forma di "cose per le quali è valida una certa relazione". Ma il creatore sta lì con le braghe calate perchè deve conoscere la definizione di ogni altro oggetto. Questo non riesco a infilarlo in nessuna casella. Il tempo e la ragione mi diranno se sia questo l'ostacolo insormontabile alla forza irresistibile.
Booch e soci di orientamento agli oggetti non hanno mai capito una fava.
E se int non fosse un oggetto?
Int e' un oggetto :D
In Java come in C#, int e' implementato come uno scalare per una questione puramente prestazionale, ma logicamente e' un oggetto. In C# puoi scrivere:
1.ToString();
(Puoi anche in java vero?)
In realta' un int segue perfettamente la definizione di oggetto, ovvero un dato al quale puoi mandare messaggi e svolge un'operazione:
1 + 1
Il messaggio + e' mandato ai due oggetti int che si sommano.
Dunque, secondo la tua definizione nessuna classe e' autonoma perche' come minimo e' in relazione di composizione con un oggetto scalare. La contraddizione e' evidente.
Supponi che int sia la relazione che intercorre tra tutti gli interi. Allora l'oggetto qui definito:
class Pippo {
private int x;
public void setX(int value) { x = value; }
public int getX() { return value; }
}
non sarebbe forse autonomo? E' "composto"? Non di un altro oggetto (sempre se int fosse un'ipotetica relazione). Usa una relazione che intercorre tra altri oggetti, l'ipotetico int.
Si', e' in relazione di composizione con int.
Ma questa non è informatica, è poesia o cinema o teatro, perchè l'unica definizione verificabile di caratteristica essenziale è "tutte quelle che l'osservatore usa per descrivere l'oggetto".
Esatto, non stai parlando di informatica :D
Secondo me spesso e volentieri ti perdi in un bicchiere d'acqua in queste discussioni e parli del sesso degl'angeli.
Quando alla fine il discorso che si cercava di fare era molto semplice: per modellare la relazione fra due oggetti A e B, e' meglio scegliere la composizione o l'ereditarieta'?
Dipende. Se i due oggetti c'e' una relazione is_a si sceglie ereditarieta', se c'e' una relazione is_implemented_in_terms_of si sceglie composizione.
Non si sceglie ereditarieta' nel secondo caso, alla fine il mio discorso era solo questo :)
Sto usando i termini "oggetto" e "classe" in maniera molto lasca, perdonami.
:D E vabbè, allora int è un oggetto perchè gli mandiamo un messaggio. 'Na bella raccomandata e via, ecco la programmazione orientata agli oggetti! E ora, tutti a battere le dita sulla tastiera che prima o poi un programma salta fuori! :D
Tu mi vuoi morto mi vuoi :D
Per carità, io sono un relativista: se mi dici che l'acqua brucia e il fuoco bagna io penso che tu abbia un punto di vista diverso dal mio e che devo cercare di comprenderlo.
Ma la teoria secondo cui uso la relazione is-a se c'è una relazione is-a e una uses-a se c'è una relazione uses-a mi lascia perplesso. E' come prendere uno che sta in mezzo ad una piscina e dirgli "hey, sei tutto bagnato": ben che vada penserà "a' Galileo, ammazza che scoperta che hai fatto!" :D
cdimauro
15-06-2006, 10:05
Io valuto l'uso di uno strumento rispetto ad un altro in base ai problemi che ho da risolvere.
Adesso mi faccio sparare da tutti e due, raccontandovi cosa combino col codice. :D :D :D
A lavoro ho sviluppato spesso delle librerie contenenti API che non hanno nemmeno una striminzita classicina. L'ultima ieri, InternetUtils che ha quest'API:
def SendMail(FromAddress, ToAddressList, Subject, Message) # direi che si commenta da sola. :D
Una cosa che odio di Java è proprio il fatto che obbliga a incapsulare tutto in una classe, quando un package può benissimo bastare per contere ciò che voglio esportare (costanti, tipi e API).
Finora il concetto di interfaccia e il tipo di relazione che instaura fra gli oggetti l'ho usato (in Python non esistono le interfacce: c'è l'ereditarietà multipla, come in C++) poche volte, per particolari applicazioni distribuite.
Per le poche classi che ho scritto, ho usato per lo più l'ereditarietà.
Ad esempio, in un particolare parser l'elemento base era una classe che esponeva dei metodi standard e soltanto alcuni di essi venivano "sovrascritti" dalle classi che la estendevano (in particolare il metodo "match" era sempre "sovrascritto" perché ovviamente cambiava la valutazione in base al fatto che l'elemento era una lista, un intero, una stringa, ecc.).
La composizione l'ho usata nella classe Parser, che "ingloba" gli elementi base (di cui parlavo prima) necessari al parsing, appunto, e si occupa di gestire tutte le fasi del parsing (ivi compresi i relativi cambiamenti di stato).
In conclusione: non so se l'approccio che ho scelto è giusto o sbagliato. Uso raramente le classi e ancor di meno le interfacce. Sarà forse un crimine, ma le soluzioni che ho trovato mi hanno permesso di portare a termine il lavoro agevolmente e velocemente, anche quando s'è tratto di rimettere mano al codice per modificarlo o estenderne le funzionalità.
OK, adesso potete caricare pure i fucili... :p
P.S. Quella della somma di due interi vista come messaggio mi ricorda molto l'approccio di SmallTalk, dove qualunque cosa si manipoli è un oggetto e le operazioni vengono viste come messaggi. Molto bello. :)
:D E vabbè, allora int è un oggetto perchè gli mandiamo un messaggio. 'Na bella raccomandata e via, ecco la programmazione orientata agli oggetti! E ora, tutti a battere le dita sulla tastiera che prima o poi un programma salta fuori! :D
Tu mi vuoi morto mi vuoi :D
Per carità, io sono un relativista: se mi dici che l'acqua brucia e il fuoco bagna io penso che tu abbia un punto di vista diverso dal mio e che devo cercare di comprenderlo.
Ma guarda che e' la definizione di oggetto. :)
Non e' che se ti dico che il cielo e' blu mi rispondi che secondo te e' a pois rosa e sei un relativista perche' ognuno ha le sue opinioni. Un int e' un oggetto perche' ha dei dati e risponde ai messaggi. E ti ricordo che la chiamata ad un metodo, in OOP, e' un messaggio spedito (si', anche attraverso raccomandata o protocolli di trasporto di rete) all'oggetto stesso.
Tratto dal sito Sun:
Definition: An object is a software bundle of variables and related methods.
Perfettamente applicabile a int come abbiamo visto.
Il fatto che la dichiarazione di un metodo sia interna alla classe o esterna (come avviene in C o puo' avvenire in C++) e' una differenza sintattica non semantica.
La definizione di metodo dice che e' una procedura che lavora su un blocco di dati e fa parte dell'interfaccia pubblica o privata dell'oggetto.
In C++
class A
{
};
void MethodOfA(A& a, ...);
MethodOfA() e' un metodo di A e fa parte della sua interfaccia (e dovrebbe essere distribuito assieme alla definizione di A). Gente come Sutter consiglia di scrivere i metodi in C++ cosi' come ho fatto io qui per ridurre il coupling fra l'implementazione del metodo e la struttura interna della classe. Non sono particolarmente d'accordo, infatti non lo faccio, ma questo discorso ha una logica ferrea sotto.
E quindi anche + per gl'int e' un metodo di int, ovvero un messaggio (perche' un metodo e un messaggio sono la stessa cosa, come una particella e un'onda sono due modi per descrivere la stessa entita' in Meccanica Quantistica).
Ma la teoria secondo cui uso la relazione is-a se c'è una relazione is-a e una uses-a se c'è una relazione uses-a mi lascia perplesso. E' come prendere uno che sta in mezzo ad una piscina e dirgli "hey, sei tutto bagnato": ben che vada penserà "a' Galileo, ammazza che scoperta che hai fatto!" :D
Ti lascia perplesso perche' non e' quello che ho scritto. Ho scritto, e lo ripeto, che se c'e' una relazione is_a questa va modellata con lo strumento dell'ereditarieta', se c'e' una relazione is_implemented_in_terms_of va modellata con lo strumento della composizione. Che cosa non e' chiaro in questa affermazione?
Ecco una definizione migliore del discorso che ho fatto su un tipo che puo' essere usato ovunque e' usato il suo tipo padre. Si chiama "principio di sostituzione di Liskov"
http://en.wikipedia.org/wiki/Liskov_substitution_principle
In object-oriented programming, the Liskov substitution principle is a particular definition of subtype that was introduced by Barbara Liskov and Jeannette Wing in a 1993 paper entitled Family Values: A Behavioral Notion of Subtyping. (It is not the only definition; see datatype.)
The principle was formulated succinctly in a subsequent paper as follows:
Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.
Thus, Liskov and Wing's notion of "subtype" is based on the notion of substitutability; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness).
A function using a class hierarchy violating the principle uses a reference to a base class but must know about all the derivatives of that base class. Such a function violates the open/closed principle because it must be modified whenever a new derivative of the base class is created.
In the design by contract methodology, the principle leads to some restrictions on how contracts can interact with inheritance:
Preconditions must be the same or weaker in a subclass. This means that you cannot have a subclass that has stronger preconditions than its superclass.
Postconditions must be the same or stronger in a subclass. This means that you cannot have a subclass that has weaker postconditions than its superclass.
In addition, these conditions must be comparable. The conditions A and B are not comparable with the conditions B and C as one set of conditions does not wholly subsume the other. Classes with incomparable pre- or postconditions are not substitutable under the principle.
Nota il discorso sulle precondizioni e le postcondizioni (i contratti di cui parlavo). L'idea e' di usare ereditarieta' solo quando questo principio di sostituzione e' valido.
*pant* *pant*
Ed infine Herb Sutter che e' decisamente piu' bravo di me a spiegare questi concetti:
http://www.artima.com/cppsource/codestandards3.html
Avoid inheritance taxes: Inheritance is the second-tightest coupling relationship in C++, second only to friendship. Tight coupling is undesirable and should be avoided where possible. Therefore, prefer composition to inheritance unless you know that the latter truly benefits your design.
1.toString in java non è ammesso ma anche se lo fosse questo non basterebbe a fare di int un oggetto.
La definizione di Sun (una delle, nelle specifiche del linguaggio oggetto è istanza di una classe, altra idea molto bizzarra) rende oggetto anche una struttura C: infatti . è un messaggio inviato alla struttura così come + è un messaggio inviato ad un int. O il punto non è un messaggio? E se non lo è, perchè? Che differenza ha il punto rispetto al più?
Non è corretto dire che siccome tu ritieni che int sia un oggetto allora io dico che nessun oggetto può essere autonomo.
Se nella definizione di una classe Pippo trovi un "new Date()" ciò significa che è stato creato un oggetto la cui definizione sta in Pippo e in Date, il che non è piacevole o spiacevole, è solo coerente con la definizione di oggetto.
Secondo la mia definizione oggetto è qualsiasi cosa di cui io possa predicare l'identità in un contesto, a prescindere da quali siano le caratteristiche sulla base delle quali io parli di identità dell'oggetto. Ciò che è richiesto ad un linguaggio per consentire la definizione di un oggetto è che io possa esprimere questa identità.
Sia C che C++ consentono di definire un oggetto ma dei due solo C++ è in grado di esprimere una relazione (il possesso di una qualsiasi caratteristica comune non espressa attraverso un oggetto) contestuale (la mimina relazione che intercorre tra due oggetti è che esistano nello stesso contesto).
Sul principio di sostituzione di Liskov devo leggermi il documento (http://citeseer.ist.psu.edu/rd/20732875%2C227598%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs/6743/ftp:zSzzSzreports.adm.cs.cmu.eduzSzusrzSzanonzSz1993zSzCMU-CS-93-187.pdf/liskov94family.pdf) prima di poter dire qualcosa. C'è qualcosa che mi torna e qualcosa che non mi torna in quello che dice wikipedia. E a me piace parlare del sesso degli angeli dopo averlo visto :D.
Non è che io dica che la definizione di oggetto che hai proposto sia sbagliata perchè l'ha detto Sun e a me piace farlo strano :D. E' che a me, applicando quella definizione, capitano cose strane.
Sutter, che a me piace tantissimo, ci dice che poichè la relazione di ereditarietà produce un accoppiamento forte e la relazione di composizione produce un accoppiamento debole, è meglio scegliere la relazione che accoppia debolmente due oggetti. E' chiaro e "geometrico" e non si può non concordare sul fatto che sia UNA soluzione. Per me ce n'è un'altra: eliminare in radice la possibilità di accoppiare oggetti. Eliminata questa possibilità a me risulta che ereditarietà e composizione cessano di essere distinte e diventano entrambe una generica relazione.
Quantitativamente tu hai due relazioni, ereditarietà e composizione, devi spiegarle entrambe e poi devi anche dire che una è preferibile all'altra il che ti porta necessariamente a dover motivare la preferenza.
Io ho in mano una sola relazione tra oggetti autonomi: non devo motivare alcuna preferenza. Per me è una visione "più semplice" se valuto la semplicità come quantità di concetti a cui far riferimento per spiegare un sistema.
1.toString in java non è ammesso ma anche se lo fosse questo non basterebbe a fare di int un oggetto.
La definizione di Sun (una delle, nelle specifiche del linguaggio oggetto è istanza di una classe, altra idea molto bizzarra) rende oggetto anche una struttura C: infatti . è un messaggio inviato alla struttura così come + è un messaggio inviato ad un int. O il punto non è un messaggio? E se non lo è, perchè? Che differenza ha il punto rispetto al più?
Il . non e' un messaggio perche' non richiede un'azione, e' un simbolo sintattico per deferenziare un campo della struttura. In C una struttura e' un oggetto se ha delle azioni che vi si svolgono sopra (come da definizione).
Il + e' un metodo perche' svolge un'azione sull'intero, che e' un oggetto (sempre secondo definizione). Il fatto che non sia implementato come oggetto in Java (mentre lo e' in altri linguaggi come Smalltak e C#), ripeto, e' solo una questione implementativa.
Non è corretto dire che siccome tu ritieni che int sia un oggetto allora io dico che nessun oggetto può essere autonomo.
Beh, deriva dalla tua definizione di autonomia di un oggetto, ovvero che non si debba basare su un altro oggetto. Definizione per altro sbagliata, perche' non si capisce perche' un oggetto composto da altri oggetti non possa essere un oggetto.
Secondo la mia definizione oggetto è qualsiasi cosa di cui io possa predicare l'identità in un contesto, a prescindere da quali siano le caratteristiche sulla base delle quali io parli di identità dell'oggetto. Ciò che è richiesto ad un linguaggio per consentire la definizione di un oggetto è che io possa esprimere questa identità.
A parte che questa e' la tua definizione di oggetto, che non e' la definizione di oggetto comune. Tu puoi definire il cielo a pois rossi, e dire che sbaglio ad affermare che il cielo e' azzurro, ma la cosa non ci porta da nessuna parte, perche' ti stai creando le tue definizioni che ti danno ragione :)
In realta' anche secondo la tua definizione, non si capisce perche' un oggetto composto da altri oggetti non debba avere una sua identita'. Una macchina non ha la sua identita' solo perche' e' composta da un motore e dalla carrozzeria? E' una posizione evidentemente indifendibile.
Sia C che C++ consentono di definire un oggetto ma dei due solo C++ è in grado di esprimere una relazione (il possesso di una qualsiasi caratteristica comune non espressa attraverso un oggetto) contestuale (la mimina relazione che intercorre tra due oggetti è che esistano nello stesso contesto).
Questo e' palesemente falso. In C puoi stabilire tutte le relazioni fra oggetti che ti possono venire in mente, e' solo piu' complesso farlo. Quando si parla di OOP non c'e' nulla che non possa essere espresso in C, tanto e' vero che i primi compilatori C++ erano dei preprocessori.
Non è che io dica che la definizione di oggetto che hai proposto sia sbagliata perchè l'ha detto Sun e a me piace farlo strano :D. E' che a me, applicando quella definizione, capitano cose strane.
A te capiteranno cose strane, ma quella e' la definizione comune di oggetto :)
Non ha molto valore logico crearsi delle proprie definizioni di oggetto e ragionare su quelle. Io potrei dirti che per me un oggetto e' un bombolone alla crema, e programmare ad oggetti significa cucinare dei gran dessert fatti di bomboloni alla crema. Ma la mia definizione non sarebbe tanto utile per alcuna attivita' pratica collegata al programmare... Esattamente come non lo e' la tua, perche' dalla tua definizione si deduce che nulla puo' essere un oggetto se non i bit.
Sutter, che a me piace tantissimo, ci dice che poichè la relazione di ereditarietà produce un accoppiamento forte e la relazione di composizione produce un accoppiamento debole, è meglio scegliere la relazione che accoppia debolmente due oggetti. E' chiaro e "geometrico" e non si può non concordare sul fatto che sia UNA soluzione. Per me ce n'è un'altra: eliminare in radice la possibilità di accoppiare oggetti. Eliminata questa possibilità a me risulta che ereditarietà e composizione cessano di essere distinte e diventano entrambe una generica relazione.
Oggetti formati di bit che vivono autonomi in Platonia come Idee Pure e scollegate l'una dall'altra? Ok, ora possiamo tornare con i piedi per terra e parlare di programmazione pero'? :)
Io ho in mano una sola relazione tra oggetti autonomi: non devo motivare alcuna preferenza. Per me è una visione "più semplice" se valuto la semplicità come quantità di concetti a cui far riferimento per spiegare un sistema.
Scusami, ma la tua non e' una visione piu' semplice, la tua e' una visione di un mondo parallelo che non esiste. Stai parlando del niente.
Questa devo dirla subito, poi leggo il resto :D
Se scrivo "secondo la mia definizione di oggetto" è chiaro che parlo della mia definizione di oggetto.
Sono d'accordo, e allora adesso ti do' la mia definizione di oggetto:
- Un oggetto e' un bombolone alla crema
Discuss :)
Ahhh, la discussione si accende, bene =).
Prima di parlare di palese falsità mi permetterei di ricordati la Turing-Tarpit, vale a dire la distinzione tra il concetto di possesso di una caratteristica e simulazione di una caratteristica in un linguaggio di programmazione.
In C puoi stabilire una relazione tra due strutture solo usando una struttura intermedia come rappresentazione della relazione. E' chiaro che se parliamo di relazione ed oggetto come due entità distinte non è possibile esprimere una relazione usando un oggetto a meno di ritenere che anche le relazioni siano oggetti, il che potrebbe essere problematico. La situazione è analoga nel caso in cui tu voglia esprimere un metodo: devi usare un puntatore a funzione, cioè devi emulare la definizione di metodo ogni volta che vuoi usare un metodo. Ne convieni o anche qui il fuoco bagna e l'acqua brucia? :boxe: :D
Faccio un esempio java-pratico per chiarire cosa intendo per perdita di autonomia "riflessa". Per farlo devo tuttavia eliminare dal linguaggio di programmazione Java la clausola "extends" tra tipi class.
Fai finta di accettare questa finzione per un attimo e seguimi:
public class A {
public void getNome() { return "a"; }
}
public class B {
private A a;
public B(A a) {
this.a = a;
}
public void getNome() {
return a.getNome();
}
}
Ripeto: fingo che la classe Java non definisca una categoria di oggetti bensi serva esclusivamente a definire un oggetto.
Ora io cambio l'oggetto A (non la classe, qui fingiamo che sia solo la definizione di UN oggetto):
public class A {
public String dimmiComeTiChiami() { return "a"; }
}
Cambio cioè l'identità di A (tutte le caratteristiche sono determinanti per l'identità di un oggetto SECONDO ME :D).
Cosa succede a B ora? Succede che B non è più valido: la sua definizione prima era possibile ora è impossibile. E' impossibile che io abbia un oggetto B, dopo che è mutato A.
Prima B era un che di valido ora è diventato invalido. Questo passaggio per me significa che B non è più "identico solo a sè stesso".
Eppure B non è stato modificato. E' stato modificato A. Il B di prima non è più identico al B di adesso (l'ultimo è impossibile) e l'identità si è persa perchè è mutato qualcos'altro, A.
E' evidente che B non fosse "identico solo a se stesso" ma "identico a se stesso più qualcos'altro". Poichè per me oggetto è ciò che è identico solo a sè stesso, ecco che oggetto PER ME è ciò che è definito insieme da A e B. Qui AB è oggetto.
Dico anche che non c'è relazione di composizione perchè, coerentemente con la MIA definizione, la relazione è l'espressione di un carattere comune a più oggetti. Qui non abbiamo più oggetti, ne abbiamo uno solo, dunque non ci può essere relazione.
A prescindere dal fatto che tu lo ritenga "moralmente" giusto o sbagliato, che ti appaia "moralmente" condivisibile o che sia una cosa corrispondente a quanto hai letto in qualche libro o a quanto tu abbia autonomamente determinato, ti sembra logico il discorso? Cioè che a partire da una definizione di oggetto in termini di identità (il motto "identico solo a sè stesso") si arrivi a quella conclusione?
Sono d'accordo, e allora adesso ti do' la mia definizione di oggetto:
- Un oggetto e' un bombolone alla crema
Discuss :)
:D:D:D Sei tremendo sei.
Però è accettabile. Infatti non esiste una logica delle definizioni, esiste solo una logica delle proposizioni. Una proposizione è vera o falsa, una definizione non è vera o falsa, è o non è.
E se ne può anche discutere. Per me vuol dire che quando vedi qualcosa che possiede tutte le caratteristiche di un bombolone alla crema tu vedi un oggetto. Tutto quello che non ha le caratteristiche di un bombolone alla crema non è un oggetto.
Discussione che per me non sarebbe assolutamente oziosa se tu credessi veramente in quella definizione e non lo dicessi tanto per prendermi per i fondelli :D.
La situazione è analoga nel caso in cui tu voglia esprimere un metodo: devi usare un puntatore a funzione, cioè devi emulare la definizione di metodo ogni volta che vuoi usare un metodo. Ne convieni o anche qui il fuoco bagna e l'acqua brucia? :boxe: :D
Non convengo, perche' un metodo e' implementato davvero cosi' come dici :)
E' solo una questione sintattica che in C un oggetto si dichiari e si usi in un certo modo e in C++ in un'altra: a livello espressivo sono perfettamente identici. Entrambi i linguaggi possono definire relazioni fra oggetti. In uno dei due e' solo enormemente piu' comodo farlo.
Faccio un esempio java-pratico per chiarire cosa intendo per perdita di autonomia "riflessa". Per farlo devo tuttavia eliminare dal linguaggio di programmazione Java la clausola "extends" tra tipi class.
A prescindere dal fatto che tu lo ritenga "moralmente" giusto o sbagliato, che ti appaia "moralmente" condivisibile o che sia una cosa corrispondente a quanto hai letto in qualche libro o a quanto tu abbia autonomamente determinato, ti sembra logico il discorso? Cioè che a partire da una definizione di oggetto in termini di identità (il motto "identico solo a sè stesso") si arrivi a quella conclusione?
Il tuo discorso e' perfettamente logico, ma sbagliato perche' parte da una premessa sbagliata: un oggetto non e' quello che hai detto tu. Un oggetto ha una definizione ben precisa e universalmente accettata, non puoi cambiartela a piacimento :)
Altrimenti io posso definire un oggetto un bombolone alla crema e costruire una teoria perfettamente logica e perfettamente legittima come la tua... ma sbagliata. In parole povere stai discutendo sul sesso degl'angeli, facendo esercizi teorici di logica, ma a livello prartico non ci stai dicendo nulla di concreto e utile perche' parti da una definizione sbagliata.
Non ci stai dicendo dati due oggetti in quali condizioni e' meglio fare composizione oppure inheritance per diminuire il coupling e, quindi, la densita' di difetti nel codice (questa e' una quantita' misurabile). Ci stai solo dicendo che data la tua definizione, arrivi a determinate conclusoni. Sbagliate, perche' la definizione e' sbagliata. E quindi di nessuna utilita' pratica quando mi metto di fronte al compilatore e devo risolvere un problema :)
:D:D:D Sei tremendo sei.
Però è accettabile. Infatti non esiste una logica delle definizioni, esiste solo una logica delle proposizioni. Una proposizione è vera o falsa, una definizione non è vera o falsa, è o non è.
E se ne può anche discutere. Per me vuol dire che quando vedi qualcosa che possiede tutte le caratteristiche di un bombolone alla crema tu vedi un oggetto. Tutto quello che non ha le caratteristiche di un bombolone alla crema non è un oggetto.
Discussione che per me non sarebbe assolutamente oziosa se tu credessi veramente in quella definizione e non lo dicessi tanto per prendermi per i fondelli :D.
Per me sarebbe oziosissima e perfettamente inutile, perche' sono un praticone e sono interessato solo a cio' che mi fa risolvere i problemi che devo affrontare. Non ci posso fare niente, sono pragmatico :D
Vedi, m'accontento di poco: m'hai fatto felice. Se accettiamo la stupidaggine che dico è logico ricavarne quelle conseguenze. Tanto mi bastava :D.
Sul fatto che la definizione di oggetto sia ben precisa e universalmente accettata avrei qualche dubbio, benchè anche a me sembri che gli elementi di accordo ruotino intorno al possesso di un elenco di stati e metodi.
Per non confondere più di quanto già fatto le idee a chi segue vale la pena di riportare almeno due righe sulla programmazione orientata agli oggetti (l'altra, quella, quella "sbagliata" :D):
1) l'elemento fondamentale della programmazione orientata agli oggetti è il Tipo. Il tipo è l'espressione di un insieme di comportamenti e proprietà osservabili riferibili ad uno o più oggetti in un sistema.
2) l'oggetto è l'esemplare di un tipo per il quale è concretamente definito come un comportamento si svolga e quali valori abbia una proprietà in un certo istante.
1) è la ragione per cui i linguaggi di programmazione orientata agli oggetti ragionano "per classi". Noi definiamo classi di oggetti e attraverso le classi definiamo relazioni tra questi oggetti. L'oggetto in senso proprio (o molto improprio :D) entra nel programma con l'uso di un qualche operatore ma è sempre visibile e manipolabile attraverso la definizione del tipo a cui appartiene.
Pare anche a voi che questi siano gli odierni elementi di accordo circa la definizione corrente di oggetto?
Decisamente ci ritroviamo.
(Stavolta te la sei cercata pero', hai fatto partire tutto da una delle rare volte che ti do' ragione! :D)
golf150cv
30-09-2006, 15:36
raga ce l'ho fatta.... ho preso 20!!! martedì registro... :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.