Newsgroup: it.comp.lang.c++
Titolo: implementazione vs interfaccia

ciao a tutti,
si sente sempre dire che bisogna separare
l'implementazione di un oggetto dalla sua interfaccia.
Questo significa, in soldoni, che per ogni oggettto
che si ha in mente, ne devo costruire una classe
astratta A da cui derivare l'oggetto in questione B.
B = implementazione.
Ma e' sempre cosi?
--
Tiberio Grasso

 wrote in message
385a6666.0@etsv0008...

No, solo per i tipi che ti interessa considerare
come polimorfici.
Pochissimi linguaggi hanno TUTTI i tipi egualmente
polimorfici.  Fra quelli diffusi, mi viene in mente
solo Smalltalk.
In tutti gli altri linguaggi, non puoi ereditare da,
che so, i numeri interi, una classe da usarsi in
modo polimorfico con essi.
Similmente, dunque, il C++ ti permette anche di
definire tu stesso altri tipi non polimorfici.  Alla
salute di quelli che invece vorrebbero che ti fosse
proibito, obbligandoti a definire _solo_ tipi
polimorfici, e non permettendoti invece di
definirne altri non-polimorfici come int o double.
Quindi: se definisci un nuovo "tipo-base", e`
meglio che non abbia nessun metodo virtuale,
e quindi, naturalmente, non vorrai definire
un'interfaccia astratta corrispondente.
Quali tipi sono "base"?  Quelli, in pratica, che
sono "puri valori", per cui cioe` gli eventuali
metodi sono puri "accessori e modificatori di
un singolo, unitario valore".  Ad esempio, se
il C++ gia` non definisse i tipi complessi (con
il solito, grazioso template), e ti trovassi
quindi a definirli tu, certamente vorrai poi
pensarli come tipo-base, per estensione del
campo numerico da double a complex.
Similmente, in tutta probabilita`, per tipi come
vettori e matrici di numeri, dall'uso puramente
computazionale.  Pero`, qui, si potrebbe iniziare
a nutrire dei dubbi; ad esempio, se le tue
matrici fossero spesso simmetriche, o sparse,
o triangolari, ecc, una loro definizione di tipo
polimorfico (quindi attraverso una base astratta)
potrebbe consentirti enormi risparmi di memoria.
D'altra parte, in casi computazionalmente cruciali
in qui le matrici sono invece dense, l'aggravio
dell'accesso polimorfico potrebbe essere serio.
In certi casi, i template possono permetterti di
avere la moglie piena e la botte ubriaca...:-).
E` una questione, dunque, delicata, risolubile
solo caso per caso, in funzione di esigenze assai
specifiche del tuo singolo progetto, o del campo
applicativo per cui stai progettando la tua
libreria di codice riusabile.
Alex

definirne altri non-polimorfici come int o double.
Se non lo permettesse, addio multi-paradigm, no?
AB
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrea Baruzzo
Via Circonvallazione, 26
Muzzana del Turgnano (UD) - Italy
e-mail: 
andrea....@ud.nettuno.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Se non lo permettesse, addio multi-paradigm, no?
Infatti.  Non mancano purtroppo gli esempi di programmatori
che, invasati dal solo paradigma O-O, vedono appunto il
multi-paradigm come un fatto _negativo_....!  Nei giorni
scorsi se ne e` dibattutto non poco su questo gruppo.
La genericita` (template) e` matematicamente basata sul
"signature-oriented polymorphism", le cui credenziali
matematiche sono impeccabili.  L'O-O, che permette degli
aspetti di polimorfismo run-time irraggiungibili in termini
di generic programming, con un _certo grado_ comunque
di sicurezza dei tipi (non necessariamente assoluta), e` un
eccellente complemento alla genericita`; le sinergie fra
questi due paradigmi (ed altri ancora, compresi alcuni
matematicamente solidissimi come quello relazionale)
permettono non di rado soluzioni davvero splendide.  Ma
non senza un costo in termini di studio, preparazione,
pratica -- e non senza un ottimo lavoro di progetto (e/o
sviluppo di prototipi, che a volte e` un gran bel modo
di progettare!-).
Alex

 definirne altri non-polimorfici come int o double.
Salute! :)))
Ciao!
-----
Giovanni Bajo
Lead Programmer
Prograph Research S.r.l.
http://www.prograph.it

di progettare!-).
Sai, leggendo l'homepage di una ditta del settore, mi ha subito colpito un'
affermazione: "...alla fine del progetto non [si] avrà solo un prodotto
migliore, ma anche un team più esperto e capace." Amo questa posizione. Tutti
coloro che si occupano di progettazione/programmazione, in un modo o nell'altro,
fanno il loro lavoro. Tuttavia temo che non siano la maggioranza coloro che lo
fanno in prospettiva, interessati anche al percorso e non solo alla destinazione
finale (ovvio che posso essere smentito).
Il C++ offre molto e, in cambio, ti chiede sicuramente degli sforzi, sforzi che
non c'è Wizard o framework o tool che tenga. Qui si deve imparare a progettare,
ma soprattutto imparare a pensare, il che richiede sempre un pizzico di
creatività (ed esperienza).
Molti sono spaventati da questa curva di apprendimento irta e complessa,
finendo per rinunciare presto. E' un peccato che non provino neppure
ad immaginare dove potrebbero arrivare, anche soltanto incamminandosi lungo la
strada. Ovviamente anche quest'ultima frase riflette considerazioni del tutto
personali, quindi mi scuso con chiunque dissenta.
Aprofitto invece per fare a te Alex e a tutti i frequentatori del NG i miei
migliori auguri di Buone Feste. Buon Natale e un sereno anno nuovo a tutti
quanti.
