franksisca
27-02-2012, 18:15
Salve, ho questa situazione:
classe persona e classe associato che estende persona.
se creo un oggetto persona e poi nel proseguo del codice lo "casto" ad associato, mi genera un errore di conversione.
viceversa no.
ora per quel che mi ricordo io con l'ereditarietà potevo aggiungere dettagli...però così facendo non solo non lo fà, ma addirittura li perdo (invertendo padre e diglio non dà problemi di casting)
Chiaro.. Un Associato(qualsiasi cosa sia) E' una Persona. Viceversa no. Quindi potrai fare un cast da Persona ad Associato solo se quel riferimento è davvero di un oggetto di tipo Associato. Pena una ClassCastException. Spero di non aver detto cavolate.
franksisca
27-02-2012, 22:21
Chiaro.. Un Associato(qualsiasi cosa sia) E' una Persona. Viceversa no. Quindi potrai fare un cast da Persona ad Associato solo se quel riferimento è davvero di un oggetto di tipo Associato. Pena una ClassCastException. Spero di non aver detto cavolate.
allora non ricordo una cippa.
Io creo una classe generica con nome, cognome e codice fiscale.
poi creo un associato (extends persona) che ha anche un id.
Se creo una oggetto persona, poi non posso "castarlo" ad associato perchè mi dà class exception. ma io quando lo creo non sò a prescindere se sarà un associato o un altra tipologia di persona!!!
se facciamo il paragone con la scuola, siamo tutte persone, ma poi ci sarà lo studente con matricola e voti, il prof con classi e materie, il bidello con mansioni...che estendono tutte persona. dove sbaglio concettualmete? oppure come devo tradurre il tutto in codice?
Casting - o conversione esplicita - ed ereditarietà sono cose diverse. Sono tutti e due meccanismi che generano polimorfismo ma si tratta di polimorfismi diversi.
Il polimorfismo della conversione è ad hoc, quello dell'ereditarietà è deduttivo.
In entrambi i casi parliamo della possibilità che qualcosa appaia come se fosse altro (formalmente sarebbe l'applicabilità di operatori appartenenti ad insiemi diversi ad uno stesso operando) ma nel primo caso, quello del casting, puoi farlo nei limiti delle regole arbitrarie stabilite dal linguaggio, nel secondo caso "l'apparenza" è la conseguenza logica dell'appartenenza dell'operando ad un sottoinsieme (cioè è deducibile e in quanto tale non richiede regole ad hoc).
Così quando diciamo che un associato è una persona stabiliamo che per associato valgono tutte le operazioni di persona PIU' qualcun'altra. Detto altrimenti, Associato ha tutte le caratteristiche di una Persona e ne ha qualcuna in più.
Puoi usare un Associato dove useresti una Persona? Sì perchè Associato ha tutte le caratteristiche di Persona e chi "vuole" una Persona la vuole per l'insieme di caratteristiche di una Persona: il quid pluris dell'Associato è irrilevante.
Puoi usare una Persona dove useresti un Associato? Son problemi: un associato ha delle qualità che una persona non possiede. Per poter usare una persona al posto di un associato il sistema dovrebbe tirare ad indovinare le caratteristiche mancanti (dovrebbe cioè indurle), che non è logico e quindi non è computabile. Tra umani non sarebbe un problema (siamo induttivi per natura).
Il polimorfismo della conversione funziona in modo del tutto diverso ed è in linea di principio arbitrario: vale perchè è consentito. Anche se non è logico.
Un int ha 32 bit, un long 64. Puoi convertire un int in un long? Sì. E i 32 bit che mancano? Se li inventa il sistema. In base ad una regola che è quella del caso comune: comunemente i numeri sono operandi di funzioni aritmetiche e puoi conservare la quantità minore trasportandola in quella maggiore azzerando l'eccesso.
Ma è facile capire l'arbitrarietà se consideriamo un significato diverso di quei 32 bit. Supponiamo che servano per esprire il concetto di massimo e minimo. Il massimo intero a 32 bit convertito in intero a 64 bit non è più il massimo: per rispettare questo significato l'invenzione richiesta sui bit mancanti dovrebbe essere diversa.
Va anche peggio nella conversione da maggiore a minore o da interi a decimali: lì perdi irrecuperabilmente il senso espresso dall'operando.
Per la conversione dei riferimenti (da Persona a Associato e viceversa) valgono regole parimenti arbitrarie che tuttavia si reggono sulla logica dell'implementazione del linguaggio.
Se parliamo di ereditarietà una Persona non può mai essere "convertita" in un Associato: gli mancano dei pezzi e non si può dedurre ciò che manca.
Il casting cosa fa: applica una regola che non deriva dal rapporto padre-figlio tra Persona e Associato ma che deriva dall'implementazione del linguaggio.
Se il riferimento X creato dalla macchina virtuale possiede tutti i metodi e i campi del tipo Y allora è perfettamente possibile usare X al posto di un Y: basta reindirizzare le chiamate. Non serve che ci sia una relazione di parentela tra il tipo di X e il tipo di Y.
Ad esempio in Scala, che è un linguaggio che gira sulla stessa jvm di java, è possibile definire dei tipi strutturali:
type Stringer = { def toString(): String }
Qui Stringer è qualsiasi cosa che possieda un metodo che si chiama toString che restituisce uno String.
Stringer è parente di Number? No, però posso usare un Number come uno Stringer. E' parente di JFrame? No, però posso usare un JFrame come fosse uno Stringer.
Sebbene sia tecnicamente possibile il casting di Java è "arbitrariamente" limitato dalla compatibilità gerarchica tra il valore runtime del riferimento da convertire e il tipo di destinazione: così in tanto puoi convertire una Persona in Associato in quanto quel riferimento di tipo Persona abbia dietro di sè, nei meandri della jvm, un Associato.
Cioè:
Persona p = new Associato();
Associato a = (Associato) p; //va bene
Persona p = Autista();
Associato a = (Associato) p;//ClassCastException
Dunque: ereditarietà = logica , casting = regole da sapere e basta.
franksisca
28-02-2012, 11:57
quindi io non posso creare un oggetto persona, e poi in un secondo tempo "trasformarlo" ad associato...giusto?
Come risolveresti quindi questo "dilemma"?
stavop pensando di creare una interfaccia PersonaInterface per "tipizzare" tutte queste figure e poi lavorarci previa instaceof...comerisolveresti tu?
EDIT: ci sto sbattendo, più che sul problema sulla logica, ma non ne riesco a venire acapo.
io concettualmente penso di dover creare prima una struttura comune alle persone, quindi diciamo nome e cognome, poi queste persone possono avere varie specializzazioni, diciamo 2, una con un campo stipendio, e una con un campo esame
inizialmente io creo un oggetto persona, che poi solo in seguito trasformo, in base ad azioni esterne, in studente/professore.
per me questa struttura dovrebbe essere persona(padre) e due classi che estendono persona. nel codice scriverei persona p =new persona()...poi in base alle operazioni esterne io trasformo p in uno studente o in un docente. ma non posso fare Docente d=p;
quindi come risolvo questa struttura? sinceramente mi sto perdendo nei ragionamenti, perchè a questo punto credo che anche con le interfaccie succeda la stessa cosa
Concettualmente quello che vuoi fare è più che ragionevole: è esatto al mille per mille.
Tizio entra in ufficio di collocamento e ne esce che è un operaio o bancario o insegnante e via discorrendo.
Di solito si usa il concetto di ruolo per affrontare l'inghippo ma è solo un modo per cercare di convincersi di poter fare quello che non si può
Il linguaggio infatti ti mette i bastoni tra le ruote.
Esiste cioè una fetta (piuttosto consistente) di realtà che la derivazione statica - a estende b - non coglie: il fatto che le cose possano cambiare classe.
Puoi ottenere un effetto simile con varie soluzioni - puoi usare un proxy o un registro o dei costruttori di copie o il predetto ruolo - ma non puoi rappresentare direttamente il semplice fatto che un certo elemento acquisisca o perda gli attributi tipici di un altra categoria di elementi senza perdere la propria identità.
Detto altrimenti possiamo scrivere:
class Persona {}
class Impiegato extends Persona {
/* composizione e rinvio */
Associato(Persona p) {...}
}
class Operaio extends Persona {
Operaio(Persona p) {...}
}
E dunque dire:
Persona p = new Persona();
Persona trovaLavoro(Persona p) {
return new Impiegato(p);
//o return new Operatio(p);
}
Ma l'intoppo sta in questo:
Persona entra = new Persona();
Persona esce = trovaLavoro(entra);
entra ed esce sono persone ma non sono la stessa persona. Ed è assolutamente problematico perchè se non puoi cambiare il tipo del riferimento circolante allora corri il rischio di trovarti nel programma due riferimenti a persone diverse che in realtà sono la stessa persona.
In Java credo che la soluzione più comune sia quella del ruolo.
interface Ruolo {
Ruolo NONE = new Ruolo() {};
}
interface Associato extends Role {}
interface Ordinario extends Role {}
class Persona {
Ruolo r = Ruolo.NONE;
Ruolo getRuolo() { return r; }
void setRuolo(Ruolo r) { this.r = r; }
}
Ma, ripeto, non ha lo stesso significato dell'idea di partenza.
franksisca
28-02-2012, 15:21
più o meno ho usato una struttura simile...mi spiego:
questa è l'interfaccia che mi tipizza tutti i tipi di persone che avrò nel mio software
public interface Persona extends Serializable{
}
questa invece è la tipologia di persona generica, ovvero tutti avranno "ALMENO" questi dati
public class PersonaGenerica implements Persona {
private String nome, cognome, dataDiNascita, luogoNascita, provinciaNascita, capNascita, codiceFiscale, mail, telefono, residenza, indirizzo;
public PersonaGenerica(Persona p) {
if (!(p instanceof PersonaGenerica)) {
return;
}
PersonaGenerica newPersona = (PersonaGenerica) p;
this.nome = newPersona.getNome();
this.cognome = newPersona.getCognome();
this.dataDiNascita = newPersona.getDataDiNascita();
this.luogoNascita = newPersona.getLuogoNascita();
this.provinciaNascita = newPersona.getProvinciaNascita();
this.capNascita = newPersona.getCapNascita();
this.codiceFiscale = newPersona.getCodiceFiscale();
this.mail = newPersona.getMail();
this.telefono = newPersona.getTelefono();
this.residenza = newPersona.getResidenza();
this.indirizzo = newPersona.getIndirizzo();
}
public PersonaGenerica(String nome, String cognome, String dataDiNascita, String luogoNascita, String provinciaNascita, String capNascita, String codiceFiscale, String mail, String telefono, String residenza, String indirizzo) {
this.nome = nome;
this.cognome = cognome;
this.dataDiNascita = dataDiNascita;
this.luogoNascita = luogoNascita;
this.provinciaNascita = provinciaNascita;
this.capNascita = capNascita;
this.codiceFiscale = codiceFiscale;
this.mail = mail;
this.telefono = telefono;
this.residenza = residenza;
this.indirizzo = indirizzo;
}
...
...
...
Questa invece è una realizzazione di associato
public class Associato extends PersonaGenerica implements Persona {
Associato(Persona p, String codiceSocio, String nomeImpresa, String sedeImpresa, String capImpresa, String provinciaImpresa, String indirizzoImpresa, String codiceFiscaleImpresa, String partitaIva, String telefonoImpresa, String cellulareImpresa, String mailImpresa, String posizioneInpsImpresa, String posizioneInailImpresa, String codeceREAImpresa, String codiceAlboArtigianiImpresa, String dataAffilizaione, String referente) {
super(p);
this.codiceSocio = codiceSocio;
this.nomeImpresa = nomeImpresa;
this.sedeImpresa = sedeImpresa;
this.capImpresa = capImpresa;
this.provinciaImpresa = provinciaImpresa;
this.indirizzoImpresa = indirizzoImpresa;
this.codiceFiscaleImpresa = codiceFiscaleImpresa;
this.partitaIva = partitaIva;
this.telefonoImpresa = telefonoImpresa;
this.cellulareImpresa = cellulareImpresa;
this.mailImpresa = mailImpresa;
this.posizioneInpsImpresa = posizioneInpsImpresa;
this.posizioneInailImpresa = posizioneInailImpresa;
this.codeceREAImpresa = codeceREAImpresa;
this.codiceAlboArtigianiImpresa = codiceAlboArtigianiImpresa;
this.dataAffiliazione = dataAffilizaione;
this.referente = referente;
this.elencoServizi = new LinkedList<Servizio>();
}
private LinkedList<Servizio> elencoServizi;
private String codiceSocio, nomeImpresa, sedeImpresa, capImpresa, provinciaImpresa, indirizzoImpresa, codiceFiscaleImpresa, partitaIva, telefonoImpresa, cellulareImpresa, mailImpresa, posizioneInpsImpresa, posizioneInailImpresa, codeceREAImpresa, codiceAlboArtigianiImpresa, dataAffiliazione, referente;
public Associato(String codiceSocio, String nomeImpresa, String sedeImpresa, String capImpresa, String provinciaImpresa, String indirizzoImpresa, String codiceFiscaleImpresa, String partitaIva, String telefonoImpresa, String cellulareImpresa, String mailImpresa, String posizioneInpsImpresa, String posizioneInailImpresa, String codeceREAImpresa, String codiceAlboArtigianiImpresa, String dataAffilizaione, String referente, String nome, String cognome, String dataDiNascita, String luogoNascita, String provinciaNascita, String capNascita, String codiceFiscale, String mail, String telefono, String residenza, String indirizzo) {
super(nome, cognome, dataDiNascita, luogoNascita, provinciaNascita, capNascita, codiceFiscale, mail, telefono, residenza, indirizzo);
this.codiceSocio = codiceSocio;
this.nomeImpresa = nomeImpresa;
this.sedeImpresa = sedeImpresa;
this.capImpresa = capImpresa;
this.provinciaImpresa = provinciaImpresa;
this.indirizzoImpresa = indirizzoImpresa;
this.codiceFiscaleImpresa = codiceFiscaleImpresa;
this.partitaIva = partitaIva;
this.telefonoImpresa = telefonoImpresa;
this.cellulareImpresa = cellulareImpresa;
this.mailImpresa = mailImpresa;
this.posizioneInpsImpresa = posizioneInpsImpresa;
this.posizioneInailImpresa = posizioneInailImpresa;
this.codeceREAImpresa = codeceREAImpresa;
this.codiceAlboArtigianiImpresa = codiceAlboArtigianiImpresa;
this.dataAffiliazione = dataAffilizaione;
this.referente = referente;
this.elencoServizi = new LinkedList<Servizio>();
}
...
...
...
per il momento questa credo sia la soluzione migliore, ovvero io creo una persona e la lascio nel sistema, nel caso in cui questa persona debba modificarsi, ne creo una nuova "copiandoci" quella esistente, ovviamente preoccupandomi di eliminarla dalle persone generiche.
Non lo so, io sono pigro, di solito scelgo la soluzione che mi fa scrivere meno codice. Lì ne vedo un sacco ma non è detto che non vada bene.
franksisca
28-02-2012, 15:51
Non lo so, io sono pigro, di solito scelgo la soluzione che mi fa scrivere meno codice. Lì ne vedo un sacco ma non è detto che non vada bene.
sono solo classi che hanno tante variabili...che ovviamente non posso eliminare.
anzi credo che il codice in linea di massima lo elimino, perchè estendendo tutti dalla classe PersonaGenerica, i metodi "comuni" non li uso più
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.