Newsgroup: it.comp.lang.visual-basic
Titolo: Problema logico di gestione oggetti. Per esperti

Ciao a tutti, mi sono bloccato su un problema di logica ad oggetti,
vorrei sapere cosa posso fare per ovviare ad un problema del genere:
Ho una classe madre che si chiama Quota, quota viene estesa in diversi
metodi da Uscita e in altri metodi da Arco (sono cose geometriche che
poco importa per la risoluzione del problema), adesso dovrei fare
UscitaArco che ha alcune caratteristiche di Arco ed alcune di uscita,
come posso fare? Facendo un diagramma dovrei fare una cosa del genere:
              QUOTA
            /              \
USCITA                 ARCO
          \                /
           USCITAARCO
Ovviamente non posso ereditare da 2 classi. Non mi sembra corretto
estendere quota su UscitaArco perchè avrei metodi doppi su Arco e
uscita ciò comporterebbe il doppio di spesa per quanto concerne la
manutenzione del codice.
Grazie a tutti per l'attenzione, Babbomarci

 manutenzione del codice.
DISCLAIMER: il fatto che ti stia rispondendo non implica che io sia un 
esperto.
Il problema non dovrebbe neanche porsi. Se una classe deve derivare 
"alcune caratteristiche" (come scrivi tu) da una classe e alcune da 
un'altra, semplicemente non stiamo parlando di ereditariet�.
Creare una classe B che eredita da una classe A perch� le servono solo 
parte delle funzionalit� messe a disposizione da A � un'errore di 
progettazione, perch� il codice client che usa B potr� fare delle cose 
che, sul piano teorico, non dovrebbero essere possibili.
L'ereditariet� prevede una relazione "�-un" tra la classe derivata e la 
superclasse. Se le cose non stanno esattamente cos�, l'ereditariet� non 
va usata.
Giustamente dici che non puoi ereditare da due classi, ma se anche lo 
potessi fare (se stessi usando C++ non gestito, ad esempio), 
commetteresti un errore proprio in virt� di quanto ho scritto sopra.
Giusto per completezza: la tua situazione � comune tra chi usa linguaggi 
che permettono l'ereditariet� multipla, ed � noto come "problema del 
diamante"
 
http://en.wikipedia.org/wiki/Diamond_problem
In conclusione, da ci� che hai scritto nel post, pare che non ci siano 
nemmeno le premesse per porsi un problema del genere, perch� UscitaArco 
non *�* (nel senso di relazione "is-a" o "�-un") n� un'Uscita n� un 
Arco, e a questo punto, se tanto mi d� tanto, forse nemmeno Uscita e 
Arco *sono* un/a Quota.
Se invece hai usato l'ereditariet� in maniera corretta ma non hai 
esposto la situazione nei termini giusti, la risposta � che non hai 
comunque scampo: la questione non � risolvibile con l'ereditariet� di 
implementazione a meno che non si decida di utilizzare un linguaggio che 
permetta, appunto, l'ereditariet� multipla.
L'unica cosa che puoi fare � affidarti all'ereditariet� d'interfaccia, 
che naturalmente non � comoda come quella di implementazione.
-- 
S.

 S.
Ciao e grazie per la risposta.
Penso che ci siano delle precisazioni da fare:
La relazione IS A la conosco, perciò sono pieneamente cosciente che
UscitaArco deve essere un Arco e deve essere anche "Uscita". Spiegando
il
problema un po' nel dettagglio mi viene da dire che ogni quota
ha un'"uscita" che ne indica le caratteristiche di stampa finale,
nel caso in cui la quota sia di tipo arco (Arco is a quota) devo avere
possibilità di
utilizzare le funzioni di uscita e le funzioni di Arco, quest'ultime
per permettermi di effettuare tutti i calcoli geometrici implementati
all'interno della classe.
Nel post dici che "L'unica cosa che puoi fare è affidarti
all'ereditarietà d'interfaccia,
che naturalmente non è comoda", ci avevo pensato anch'io ma prima di
mettermici
dietro mi chiedevo se ci fosse qualcosa di meglio che magari non
conosco.
Spero di essere stato più chiaro, grazie ancora
Babbo

 all'interno della classe.
In questo periodo sono un po' fuso. Forse � per questo che, anche 
leggendo e rileggendo, non riesco ad avere un quadro chiaro della 
situazione (nel senso che non riesco a capire cosa deve fare ciascuna 
classe).
Tuttavia (correggimi se sbaglio), da quanto riesco a ricostruire, Uscita 
� una sorta di "collezione" (o "insieme", passami i termini) di 
impostazioni/opzioni che controlla quella che sar� la rappresentazione 
di Arco.
E' corretto? E inoltre, Uscita rappresenta semplicemente questo? O anche 
dell'altro?
Dici che Uscita espone dei metodi: cosa fanno? Disegnano (o forniscono 
una rappresentazione di qualche genere) di un oggetto che viene loro 
passato?
Espone delle propriet� che controllano come deve venire rappresentato 
tale oggetto (propriet� che, in quel caso, sarebbe meglio fossero 
esposte direttamente dalla classe dell'oggetto)?
Ora, forse � una coincidenza, ma il fatto che tu abbia usato proprio 
l'espressione ...ogni quota *HA UN*'Uscita... sembrerebbe indicare che 
Uscita si trovi ad essere in una relazione di *composizione* piuttosto 
che di ereditariet�.
Ammesso che ci� sia vero, io farei diventare Uscita una classe separata 
(o magari un nested type di Quota).
 > Nel post dici che "L'unica cosa che puoi fare � affidarti
 > all'ereditariet� d'interfaccia,
 > che naturalmente non � comoda", ci avevo pensato anch'io ma prima di
 > mettermici
 > dietro mi chiedevo se ci fosse qualcosa di meglio che magari non
 > conosco.
Probabilmente sbaglio, ma ho l'impressione che il problema appaia pi� 
complesso di quanto sia in realt�.
Solo che, come ho detto, mi sfugge il quadro generale.
Se Uscita controlla solo la rappresentazione grafica di un oggetto della 
classe Quota (o uno che da tale classe eredita), allora non deve ereditare.
Eventualmente, se riesci, prova a portarmi un esempio pi� astratto di 4 
classi che siano nella stessa relazione di dipendenza, che mi renda 
possibile capire il problema anche senza conoscere i dettagli della tua 
implementazione.
Io proverei, inoltre, a scomporre la gerarchia che hai creato in pi� 
classi: magari hai radunato nella stessa classe propriet� e metodi che, 
in ultima analisi, non sono proprio cos� correlati tra loro.
-- 
S.