Forum Informatica Unict

LAUREA TRIENNALE (D.M. 270/04) => Programmazione 1, 9 CFU => Topic started by: top_broker on 02-02-2010, 20:11:42



Title: 3° parte
Post by: top_broker on 02-02-2010, 20:11:42
Salve a tutti!
Volevo sapere se qualcuno di voi sa se è prevista un'ulteriore sessione della 3° prova oltre a quella di domani 3 febbraio e a quella di metà febbraio... mi sembra il 16...
Chi sa qualcosa mi faccia sapere grazie  :[Emoticon] PC Asd:


Title: Re:3° parte
Post by: ilpuglio on 02-02-2010, 22:23:05
Il professore ha detto che la prossima III parte sarà al prossimo appello che comincia la settimana dopo il 16 febbraio...


Title: Re:3° parte
Post by: top_broker on 04-02-2010, 11:17:17
 :-OK


Title: Re:3° parte
Post by: isuccia89 on 04-02-2010, 11:27:23
Approfitto di questo topic per chiedere se qualcuno può postare gentilmente il testo della terza parte di ieri.  :pray
Grazie in anticipo


Title: Re:3° parte
Post by: XDnl on 04-02-2010, 15:10:39
Ecco il testo:
Si consideri la seguente situazione che si vorrebbe modellare con un opportuno insieme di classi JAVA:

Si vuole creare un database di oggetti geometrici. Una figura geometrica, bidimensionale o tridimensionale, è caratterizzata da un nome, ed  è assegnata mediante le coordinate cartesiane dei suoi vertici. Ogni figura piana è caratterizzata da un codice (float), e quelle solide da un colore (char). Si vogliono considerare triangoli, rettangoli, quadrati e parallelepipedi. Tutte le figure piane possono essere ruotate di un certo angolo; i triangoli però subiscono una rotazione particolare. Rettangoli (e quadrati) hanno l'attributo spessore di linea. Per tutte le figure considerate ha senso calcolare un coefficiente di simmetria; per quelle piane ha senso calcolare l'area. Ogni parallelepipedo contiene al proprio interno una videocamera, caratterizzata dal numero seriale (20 caratteri), dalla data di fabbricazione e da una memoria da 1 KB.

A: analisi e disegno.
Riportare il diagramma UML di tutte le classi che si ritengono necessarie alla corretta descrizione e rappresentazione della situazione sopra descritta. Nella gerarchia ereditaria si considerino anche i seguenti metodi eventualmente polimorfi e se ne dia un'implementazione:
getTotale; restituisce il numero di figure create fino all'istante di invocazione del metodo;
getNumVertici; restituisce il numero di vertici della figura;
getVideocamera; restituisce la videocamera interna;
getCoefficiente; restituisce il coefficiente di simmetria per ogni figura calcolato mediante la formula:
c * Area per i triangoli,
c^5 * Codice / 0.9 per i rettangoli,
7*c + 3 * L + NumeroVertici per i parallelepipedi,
dove c è un coefficiente costante per tutte le figure ed L è il lato più lungo del parallelepipedo considerato.
B: utilizzo delle classi.
Si fornisca un frammento di programma che descriva la creazione e l'inizializzazione casuale di una collezione di 50 fiugre geometriche e
si visualizzino le informazioni per ogni figura,
si trovi la figura piana con il codice minore,
si ordinino (in base al coefficiente di simmetria) in un array indipendente tutti i quadrati della collezione (gli oggetti non devono essere clonati).
 
Oddio mi sono dimenticato di svolgere il primo punto!!  .huh   .huh :-)|
Avevamo un'ora e venti per svolgere il compito.


Title: Re:3° parte
Post by: Flyer on 04-02-2010, 16:18:12
Si potrebbe avere anche la soluzione di questa terza parte?


Title: Re:3° parte
Post by: XDnl on 04-02-2010, 18:04:15
Si potrebbe avere anche la soluzione di questa terza parte?
Potrei postarvi la mia, ma chi vi garantisce che sia corretta?   :[Emoticon] PC Asd:  :"-(


Title: Re:3° parte
Post by: Flyer on 04-02-2010, 19:26:44

Potrei postarvi la mia, ma chi vi garantisce che sia corretta?   :[Emoticon] PC Asd:  :"-(
Va be non ti preoccupare. Va bene lo stesso  :[Emoticon] Asd:


Title: Re:3° parte
Post by: XDnl on 04-02-2010, 20:15:31
Ecco la mia soluzione (a vostro rischio e pericolo  |-O)
Diagramma UML (i nomi delle classi ed i metodi scritti in corsivo sono astratti))
http://img229.imageshack.us/img229/9383/diagrammadiclasse5.jpg (http://img229.imageshack.us/img229/9383/diagrammadiclasse5.jpg)

Codice punto A:
Code:

// Vi posto la classe quasi per intero, anche se non richiesto dal testo
abstract class FiguraGeometrica
{
protected String nome;
protected Vertice[] vert;
public static float c = 1.0f;
private static int nIstanze = 0;

public FiguraGeometrica(String nome, Vertice[] vert)
{
this.nome = nome;
this.vert = vert;
nIstanze++;
}

...

public String getNome() { return nome; }
public int getNumVertici() { return vert.length; }
public static int getTotale() { return nIstanze; }

...
}

class Parallelepipedo extends FiguraSolida
{
...

public Videocamera getVideocamera() { return cam; }
public float getCoefficiente()
{
return 7 * FiguraGeometrica.c + 3 * getMaxL() + getNumVertici();
}

...
}

class Rettangolo extends FiguraPiana
{
...

public float getCoefficiente()
{
return (float)(Math.pow(c, 5) * codice / 0.9);
}

...
}


class Triangolo extends FiguraPiana
{
...

public float getCoefficiente()
{
return FiguraGeometrica.c * area();
}

...
}

Codice punto B:
Code:
public static void main(String[] args)
{
// Generazione casuale di 50 elementi
FiguraGeometrica[] v = new FiguraGeometrica[50];
for (int i = 0; i < v.length; i++)
switch ((int)(Math.random() * 4))
{
case 0:
v[i] = new Triangolo(...);
break;
case 1:
v[i] = new Rettangolo(...);
break;
case 2:
v[i] = new Quadrato(...);
break;
case 3:
v[i] = new Parallelepipedo(...);
break;
}

// Si visualizzino le informazioni per ogni figura
for (int i = 0; i < v.length; i++)
System.out.println(v[i].toString());

// Si trovi la figura piana con il codice minore
int minIndex = -1;
float minCode = 0;
for (int i = 0; i < v.length; i++)
if (v[i] instanceof FiguraPiana && (v[i].getCoefficiente() < minCode || minIndex == -1))
{
minIndex = i;
minCode = v[i].getCoefficiente();
}

// Si ordinino, in base al coefficiente di simmetria,  in un array indipendente tutti i quadrati
// della collezione (gli oggetti non devono essere clonati).
int nQ = 0;
for (int i = 0; i < v.length; i++)
if (v[i] instanceof Quadrato) nQ++;

Quadrato[] v2 = new Quadrato[nQ];
int last = 0;
for (int i = 0; i < v.length; i++)
if (v[i] instanceof Quadrato)
{
v2[last] = (Quadrato)(v[i]);
last++;
}

for (int i = 0; i < v2.length - 1; i++)
for (int j = i + 1; j < v2.length; j++)
if (v2[i].getCoefficiente() > v2[j].getCoefficiente())
{
Quadrato temp = v2[i];
v2[i] = v2[j];
v2[j] = temp;
}
}


Title: Re:3° parte
Post by: isuccia89 on 05-02-2010, 10:21:09
Ecco il testo:
Si consideri la seguente situazione che si vorrebbe modellare con un opportuno insieme di classi JAVA:

Si vuole creare un database di oggetti geometrici. Una figura geometrica, bidimensionale o tridimensionale, è caratterizzata da un nome, ed  è assegnata mediante le coordinate cartesiane dei suoi vertici. Ogni figura piana è caratterizzata da un codice (float), e quelle solide da un colore (char). Si vogliono considerare triangoli, rettangoli, quadrati e parallelepipedi. Tutte le figure piane possono essere ruotate di un certo angolo; i triangoli però subiscono una rotazione particolare. Rettangoli (e quadrati) hanno l'attributo spessore di linea. Per tutte le figure considerate ha senso calcolare un coefficiente di simmetria; per quelle piane ha senso calcolare l'area. Ogni parallelepipedo contiene al proprio interno una videocamera, caratterizzata dal numero seriale (20 caratteri), dalla data di fabbricazione e da una memoria da 1 KB.

A: analisi e disegno.
Riportare il diagramma UML di tutte le classi che si ritengono necessarie alla corretta descrizione e rappresentazione della situazione sopra descritta. Nella gerarchia ereditaria si considerino anche i seguenti metodi eventualmente polimorfi e se ne dia un'implementazione:
getTotale; restituisce il numero di figure create fino all'istante di invocazione del metodo;
getNumVertici; restituisce il numero di vertici della figura;
getVideocamera; restituisce la videocamera interna;
getCoefficiente; restituisce il coefficiente di simmetria per ogni figura calcolato mediante la formula:
c * Area per i triangoli,
c^5 * Codice / 0.9 per i rettangoli,
7*c + 3 * L + NumeroVertici per i parallelepipedi,
dove c è un coefficiente costante per tutte le figure ed L è il lato più lungo del parallelepipedo considerato.
B: utilizzo delle classi.
Si fornisca un frammento di programma che descriva la creazione e l'inizializzazione casuale di una collezione di 50 fiugre geometriche e
si visualizzino le informazioni per ogni figura,
si trovi la figura piana con il codice minore,
si ordinino (in base al coefficiente di simmetria) in un array indipendente tutti i quadrati della collezione (gli oggetti non devono essere clonati).
 
Oddio mi sono dimenticato di svolgere il primo punto!!  .huh   .huh :-)|
Avevamo un'ora e venti per svolgere il compito.

grazie  .wink


Title: Re:3° parte
Post by: R3m on 11-02-2010, 09:47:06
Ecco la mia soluzione (a vostro rischio e pericolo  |-O)
Diagramma UML (i nomi delle classi ed i metodi scritti in corsivo sono astratti))
http://img229.imageshack.us/img229/9383/diagrammadiclasse5.jpg (http://img229.imageshack.us/img229/9383/diagrammadiclasse5.jpg)

Ho letto il tuo UML ma mi sorge un dubbio...come mai dichiari abstract le classi Vertice e FiguraSolida senza però che queste abbiano dei metodi abstract?


Title: Re:3° parte
Post by: XDnl on 11-02-2010, 10:49:29
Ho letto il tuo UML ma mi sorge un dubbio...come mai dichiari abstract le classi Vertice e FiguraSolida senza però che queste abbiano dei metodi abstract?

La classe FiguraGeometrica è abstract, e contiene il metodo astratto getCoefficiente().
La classe FiguraSolida è abstract perchè eredita da FiguraGeometrica, ma NON implementa il metodo astratto getCoefficiente().
Volendo scendere ancora nella gerarchia, ad esempio nella classe Parallelepipedo, essa eredita da FiguraSolida, ma poichè implementa il metodo getCoefficiente() non è astratta.

Per quanto riguarda la classe Vertice ho preferito dichiararla astratta per "forzare" un eventuale programmatore ad utilzzare solamente le sottoclassi Vertice2D e Vertice3D.
Una classe, infatti, può essere dichiarata abstract anche se non contiene alcun metodo astratto, e si comporterà allo stesso modo, cioè non potrà essere istanziata direttamente.

 
Comunque credo che la mia soluzione vada abbastanza bene, visto che la valutazione è stata positiva.  :[Emoticon] PC Asd:


Title: Re:3° parte
Post by: R3m on 11-02-2010, 11:11:45
Ho letto il tuo UML ma mi sorge un dubbio...come mai dichiari abstract le classi Vertice e FiguraSolida senza però che queste abbiano dei metodi abstract?

La classe FiguraGeometrica è abstract, e contiene il metodo astratto getCoefficiente().
La classe FiguraSolida è abstract perchè eredita da FiguraGeometrica, ma NON implementa il metodo astratto getCoefficiente().
Volendo scendere ancora nella gerarchia, ad esempio nella classe Parallelepipedo, essa eredita da FiguraSolida, ma poichè implementa il metodo getCoefficiente() non è astratta.

Per quanto riguarda la classe Vertice ho preferito dichiararla astratta per "forzare" un eventuale programmatore ad utilzzare solamente le sottoclassi Vertice2D e Vertice3D.
Una classe, infatti, può essere dichiarata abstract anche se non contiene alcun metodo astratto, e si comporterà allo stesso modo, cioè non potrà essere istanziata direttamente.

quindi se ho capito bene bisogna dichiarare nella gerarchia le classi "figlie" astratte finchè non si arriva a una classe che implemente il dato metodo astratto giusto?

Comunque credo che la mia soluzione vada abbastanza bene, visto che la valutazione è stata positiva.  :[Emoticon] PC Asd:

non avevo messo in dubbio la cosa...invece tu non ascoltare me perchè ho preso 14 ( xD) quindi...


Title: Re:3° parte
Post by: XDnl on 11-02-2010, 11:15:14
quindi se ho capito bene bisogna dichiarare nella gerarchia le classi "figlie" astratte finchè non si arriva a una classe che implemente il dato metodo astratto giusto?
Esatto. In particolare, TUTTI i metodi che sono astratti (nel nostro esempio ce n'era uno solo).

Comunque credo che la mia soluzione vada abbastanza bene, visto che la valutazione è stata positiva.  :[Emoticon] PC Asd:

non avevo messo in dubbio la cosa...invece tu non ascoltare me perchè ho preso 14 ( xD) quindi...
Tranquillo  :-OK


Title: Re:3° parte
Post by: aryanna on 16-02-2010, 12:07:58
ragazzi nn riesco a capire alcuni punti allora.. prima di tutto la cosa più semplice:
il getCoefficiente dei parallelepipedi è trovato in base alla formula 7*c+3*L..... questo L è trovato con un metodo che restituisce il lato più lungo di questa figura, ma è necessario crearlo proprio questo metodo?
poi non riesco proprio a capire come funziona la classe Vertice, se la variabile che ha è un array di float, come fa poi il costruttore ad essere fatto passando (nComponenti: int)? non capisco per lo più cosa sono...
grazie!! :-ciao


Title: Re:3° parte
Post by: corsair on 16-02-2010, 12:59:09
Mi sorge una domanda.. quanto tempo si ha per la terza prova?
ho provato a svolgere l'esempio che c'è sul sito del professore, bisogna disegnare ben 8 classi...
chiave<--chiave a scorrimento<----chiave elettronica<----(1)con microchip<-----(2)banda magnetica
da scorrimento deriva pure chiave meccanica.. inoltre ho aggiunto due altre classi di supporto (data e dente).
per disegnare tutto il grafico uml ci vuole un bel po di tempo senza contare eventuali note che spiegano i metodi!(che a questo punto non saprei dove infilare, perchè non c'è più spazio!)

Come si fa dunque??
avete consigli? le note che spiegano i metodi vanno inserite? come si fa se non c'è lo spazio??


Title: Re:3° parte
Post by: corsair on 16-02-2010, 13:28:38
Aggiungo un altro dubbio... riporto il testo dell'esempio descritto prima:

    Una chiave è caratterizzata dalla descrizione e dal peso. Le chiavi possono essere di
tipo meccanico, a banda magnetica, con microchip. Queste ultime montano un chip con la
data di aggiornamento del firmware e con 3Kb di memoria. Le chiavi a banda magnetica
sono caratterizzate dall’ampiezza della banda, quelle meccaniche da una sequenza di
dentelli, ognuno caratterizzato dall’altezza del dente, dal suo profilo e dal suo coefficiente
di attrito. Le chiavi elettroniche (magnetiche e microchip) contengono le informazioni
relative all’abilitazione (livello di sicurezza, zona di abilitazione, data scadenza) delle
stesse. Sia le chiavi elettroniche che quelle meccaniche sono chiavi a scorrimento; sono
caratterizzate dalla lunghezza e possono essere bloccate internamente. Dopo il blocco le
chiavi meccaniche sono restituite, mentre quelle elettroniche non sono restituite. Infine,
esiste un’operazione per l’aggiornamento del firmware delle chiavi con microchip.


occorre secondo voi mettere nella classe chiave la descrizione che poi non verrà mai utilizzata?
Basta mettere lo stretto necessario alla soluzione dei quesiti che seguono?

il testo dice questo :
Riportare il diagramma UML di tutte le classi che si ritengono necessarie alla corretta descrizione e
rappresentazione della situazione sopra descritta.

Grazie a presto


Title: Re:3° parte
Post by: 207 on 16-02-2010, 16:53:52
La prova ha una durata di 80 minuti, bisogna fare soltanto quello che c'e scritto, quindi credo proprio che la descrizione vada inserita, per risolvere il problema io ho utilizzato anche una classe Chip e una classe Abilitazione, quali sono le classi astratte? e dove hai inserito il metodo astratto getCosto()? .arrossisco


Title: Re:3° parte
Post by: corsair on 16-02-2010, 18:18:02
beh semplice.. le classi astratte sono quella "chiave" "scorrimento" ed "elettronica" getCosto() va dichiarato abstract in chiave
e poi va implementato in meccanica, magnetica e chiave con microchip.
scusa a cosa ti serve la classe microchip? e quella abilitazione? credo che siano eccessive


Title: Re:3° parte
Post by: XDnl on 16-02-2010, 19:18:51
ragazzi nn riesco a capire alcuni punti allora.. prima di tutto la cosa più semplice:
il getCoefficiente dei parallelepipedi è trovato in base alla formula 7*c+3*L..... questo L è trovato con un metodo che restituisce il lato più lungo di questa figura, ma è necessario crearlo proprio questo metodo?
Beh, diciamo che è molto conveniente farlo.  :[Emoticon] PC Asd: Mi spiego meglio:
nella terza prova bisogna implementare direttamente solo i metodi specificati nel testo... tra questi c'è il metodo getCoefficiente(). Ora, per il parallelepipedo è necessario sapere il suo lato più lungo... se non crei il metodo getMaxL() (dovrebbe chiamarsi così se non erro), sei costretto a fornirne un'improbabile implementazione all'interno del metodo getCoefficiente(). Per fare questo devi perdere tempo ed inoltre è facile scrivere cose errate. Dichiarando il metodo getMaxL() all'interno della classe Parallelepipedo, invece, ti permette di utilizzare il metodo dentro getCoefficiente(), ma poichè getMaxL() non è specificato nel testo, non devi scrivere la sua implementazione.
Con questa "furbata" quindi hai risolto il problema, il codice all'interno di getMaxL() potrebbe essere complicatissimo, ma a te non importa.
E' fondamentale non perdere tempo durante la terza prova, visto che è davvero poco.

poi non riesco proprio a capire come funziona la classe Vertice, se la variabile che ha è un array di float, come fa poi il costruttore ad essere fatto passando (nComponenti: int)? non capisco per lo più cosa sono...
grazie!! :-ciao
Innanzitutto ricordo che quel diagramma UML è stato il mio modo di affrontare il problema,  :[Emoticon] PC Asd:, e che ovviamente non è l'unico.
La classe Vertice contiene all'interno un'array di float.
Ogni elemento dell'array rappresenta una componente del vertice.
Il parametro nComponenti del costruttore indica da quante componenti è composto.
Di fatto quindi la classe Vertice rappresenta un vertice n-dimensionale. Di seguito riporto l'implementazione:
Code:
abstract class Vertice
{
public float[] componenti;
public Vertice(int nComponenti)
{
componenti = new float[nComponenti];
}
}

class Vertice2D extends Vertice
{
public Vertice2D(int x, int y)
{
super(2);
componenti[0] = x;
componenti[1] = y;
}
}

class Vertice3D extends Vertice
{
public Vertice3D(int x, int y, int z)
{
super(3);
componenti[0] = x;
componenti[1] = y;
componenti[2] = z;
}
}
Come vedi, le classi Vertice2D e Vertice3D non fanno altro che creare un vertice rispettivamente bidimensionale/tridimensionale, richiamando il costruttore.

ho provato a svolgere l'esempio che c'è sul sito del professore, bisogna disegnare ben 8 classi...
chiave<--chiave a scorrimento<----chiave elettronica<----(1)con microchip<-----(2)banda magnetica
da scorrimento deriva pure chiave meccanica.. inoltre ho aggiunto due altre classi di supporto (data e dente).
per disegnare tutto il grafico uml ci vuole un bel po di tempo senza contare eventuali note che spiegano i metodi!(che a questo punto non saprei dove infilare, perchè non c'è più spazio!)

Come si fa dunque??
avete consigli? le note che spiegano i metodi vanno inserite? come si fa se non c'è lo spazio??
Allora, se per note intendi tipo quei "fumetti" con all'interno la descrizione dei metodi, ti dico che NON devi assolutamente metterli. Fondamentalmente per due motivi:
1) Occupano spazio (e ce n'è poco, a quanto hai visto)  :-)|
2) Occupano tempo (e purtroppo ce n'è poco anche di questo)  :-)|
occorre secondo voi mettere nella classe chiave la descrizione che poi non verrà mai utilizzata?
Assolutamente sì, devi mettere tutto quello che ti specifica nel testo.

Basta mettere lo stretto necessario alla soluzione dei quesiti che seguono?
Devi mettere quello che serve, (vedi appunto l'esempio di getMaxL(), che pur non essendo specificato nel testo, è molto conveniente mettere).

beh semplice.. le classi astratte sono quella "chiave" "scorrimento" ed "elettronica" getCosto() va dichiarato abstract in chiave
e poi va implementato in meccanica, magnetica e chiave con microchip.
scusa a cosa ti serve la classe microchip? e quella abilitazione? credo che siano eccessive
Quando ho fatto l'esercizio ho previsto le seguenti classi:
- abstract Chiave
- abstract Scorrimento extends Chiave
- abstract Elettronica extends Scorrimento
- Magnetica extends Elettronica
- Microchip extends Elettronica
- Meccanica extends Scorrimento
- Dentello  :yoh

 :-ciao  :-OK





Title: Re:3° parte
Post by: aryanna on 17-02-2010, 08:52:37
Grazie! sei stato gentilissimo!  .smile .smile .smile  e chiarissimo!


Title: Re:3° parte
Post by: corsair on 18-02-2010, 09:15:56
un ultima domanda... nelle classi astratte le variabili conviene metterel # vero? così si evitano tutti i getVariabile()
c'è un modo nei metodi costruttori per non riscrivere tutte le variabili che servono per l'inizializzazione della superclasse?
Ad esempio si possono lasciare dei puntini e poi mettere le nuove variabili?

Grazie a presto!


Title: Re:3° parte
Post by: crypt0 on 20-02-2010, 11:24:57
Dipende.
Se tutte le sottoclassi ne hanno bisogno allora puoi metterle protected, altrimenti devi fare necessariamente il getXXX() per non riempire di variabili di istanza sottoclassi che non hanno alcun bisogno di tali variabili.

E comunque sono quasi convinto che non si possa ricorrere a mezzucci com i tre puntini (purtroppo).

Ho una domanda.
Nell'esercitazione sulla terza prova svolta in aula prima della fine delle lezioni il prof ha messo i commenti anche sui metodi costruttori (che io ricordi).
Dobbiamo farlo necessariamente anche noi?


Title: Re:3° parte
Post by: corsair on 20-02-2010, 11:38:15
Dipende.
Se tutte le sottoclassi ne hanno bisogno allora puoi metterle protected, altrimenti devi fare necessariamente il getXXX() per non riempire di variabili di istanza sottoclassi che non hanno alcun bisogno di tali variabili.
Scusa ma il tuo ragionamento non torna! se una variabile sta in una superclasse, vuol dire che è necessaria a tutte le sottoclassi. Se no andrebbe messa solo nelle sottoclassi dove va inserita :-OK qualcuno mi corregga se sbaglio


Title: Re:3° parte
Post by: crypt0 on 20-02-2010, 11:49:21
E io cosa ho detto? O.o

Il ragionamento dovrebbe essere questo:
Nella superclasse metti solo le variabili in comune a tutte le sottoclassi.

Le variabili specifiche vanno inserite direttamente nelle sottoclassi che ne hanno bisogno.

Se nella struttura ereditaria alcune sottoclassi non necessitano di certe variabili, queste non devono essere istanziate nella superclasse, o comunque non devono essere accessibili al di fuori di essa.
Non esistendo una visibilità "selettiva" all'interno di una gerarchia ereditaria non ti resta altro da fare che dichiararla private e predisporre un getXXX()

Nel predisporre il polimorfismo di alcuni metodi può capitare di istanziare variabili che non sono utili a tutti.


Title: Re:3° parte
Post by: corsair on 20-02-2010, 12:07:29
ok forse stiamo vedendo la cosa da due punti diversi....per questo forse non ti comprendevo, vediamo se adesso ho capito quello che vuoi dire tu...

Tu sostieni che se una certa variabile x(quale potrebbe essere la stringa che indica il nome) che sarà presente in in tutte le classi ma non viene utilizzata nei metodi delle sottoclassi, conviene dichiararla privata  ed inserire il getXXX().

Ho capito bene?


Title: Re:3° parte
Post by: crypt0 on 20-02-2010, 12:23:20
Più o meno.

È capitato in alcune prove svolte in aula che il prof istanziava variabili di appoggio (tipo M) utilizzate da metodi di alcune sottoclassi, ma in comune a tali sottoclassi.

La cosa più sensata è dichiararla in comune ma limitarne l'accesso alla sola superclasse tramite il getM(), ereditato poi dalle sottoclassi.

Mi è capitato durante la prova di laboratorio, e ho dovuto istanziare il getM().


Title: Re:3° parte
Post by: Flyer on 24-02-2010, 16:48:14
Nella gerarchia ereditaria si considerino anche i seguenti metodi eventualmente polimorfi e se ne dia un'implementazione
Ma il prof come implementazione cosa intende?
Bisogna scrivere le classi solo con i metodi chiesti? Senza mettere variabili e altri metodi che non servono tipo?