Programmazione orientata agli ogg:interfacce ,implements, abstract e liste!!dove?

[golf150cv]

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

[rayman2]

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]

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 esempio

Comparable [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 diccelo

nomi 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]

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

[peppedx]

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 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.

[PGI-Bis]

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.

[fek]

Originariamente inviato da PGI-Bis

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]

Gli ultimi due messaggi sono delle autentiche perle. Il thread meriterebbe d'esser messo in rilievo.

[thebol]

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

[rayman2]

confermo, grazie per le utili precisazioni.

[PGI-Bis]

Originariamente inviato da cdimauro

Gli ultimi due messaggi sono delle autentiche perle. Il thread meriterebbe d'esser messo in rilievo.

Allora siam messi proprio bene . 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]

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.

[jappilas]

Originariamente inviato da PGI-Bis

Allora siam messi proprio bene . 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

Originariamente inviato da thebol

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]

Originariamente inviato da thebol

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è ...

[thebol]

Originariamente inviato da jappilas

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è ...

beh si, i fondamenti classici sono l'incapsulamento, ereditarietà e il poliformismo.

[jappilas]

Originariamente inviato da thebol

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...

[PGI-Bis]

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 .

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? .

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?

[fek]

Originariamente inviato da PGI-Bis

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
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 .

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/resource...ssDiagrams.pdf

[PGI-Bis]

Al solito iniziamo a tirarci l'un l'altro addosso petizioni di principio .

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 .

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 .

Sul martello, avevo frainteso quanto hai scritto. Non concordo sui presupposti (non sia mai ) 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).

[fek]

Originariamente inviato da PGI-Bis

Al solito iniziamo a tirarci l'un l'altro addosso petizioni di principio .

Altrimenti dov'e' il divertimento?

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.