Newsgroup: it.comp.lang.c++
Titolo: Paradigma: OOP Vs C-Style

Salve a tutti cari colleghi! ;)
E' da molto che lurko questo NG (insieme al comp.lang.c++), vorrei
contribuire con qualche bella discussione "costruttiva".
Tema del giorno:   :-)  (chi ha già sbadigliato???)
IL PARADIGMA - OOP, procedurale, modulare o... un mix?
Sappiamo tutti della grande flessibilità del C++, risulta molto affascinante
(beh, almeno personalmente :-P) poter stendere il codice in forme
molteplici, IMHO si potrebbe assimilare la creazione di un software ad una
forma d'arte.
Qual'è il vostro stile?
Un esempio: me medesimo. Studiandomi posso notare che la mia provenienza dal
monto "Assembly", M68000 in principio e Ix86 in seguito (purtroppo...), ed
il mio seguente passaggio al C, mi avevano condizionato all'uso massiccio di
puntatori, procedure e strutture dati "selvaggie"... In seguito, con
l'avvento del C++ e l'adozione della programmazione ad oggetti, mi sono
dovuto chiaramente adeguare ma, a volte, le mie radici da "smanettone"
riemergono... :)))
Che ne pensate?
Spero non sia un thread noioso...
Salutoni!
Sandro
(per chi mai volesse scrivermi in privato: togliere NO e SPAM
dall'indirizzo)

 IL PARADIGMA - OOP, procedurale, modulare o... un mix?
Un mix. Sarebbe far prova di manco d'intelligenza di limitarsi artificialmente a un metodo al
detrimento degli altri. In breve, adopera ciň che ha piů senso per il problema dato.
Fine discorso. :-)
Claudio Puviani

 Qual'è il vostro stile?
Dipende dal contesto.
Se si deve sviluppare un algoritmo di compressione dati penso che
qualche funzione C possa bastare.
Al limite si puo' impacchettare in usa libreria.
Se invece si usa il C++ su un grosso progetto usando OOP (circa una
ventina di sviluppatori),
secondo me bisogna abbracciare completamente la tecnologia ad oggetti e
concentrarsi tantissimo
sul design, che deve esssere fatto da *bravi* sviluppatori che conoscano
bene il dominio problema.
Trovo che sia assolutamente deleterio mischiare C-style nel senso di
funzioni e strutture "selvaggie" e OOP.
Meglio pasticciare completamente o (tentare) la strada OOP
completamente.
Lo dico perche' mi capita di lavorare su progetti in cui c'e' il "mix" e
sono assolutamente non manutenibili (vedi il thread "lettera aperta" del
30-01).
Se il progetto "mix" e' molto grosso ed e' costato tanto qualcuno un
giorno ti chiedera' di estenderlo. Il fatto che sia il C++ usando un po'
di OOP sara' la *scusa* per tentare di riusarlo.
Meglio allora scrivere una schifezza di codice C ultra-ottimizzato che
sara' buttato via e non esteso per il prossimo progetto.
Ciao,
Cesare

 funzioni e strutture "selvaggie" e OOP. Meglio pasticciare completamente
Beh,secondo me dipende dal contesto. Potrebbe avere senso dividere un
progetto tra codice C-style e codice OOP, tenendo però separate le
gestioni e le finalità dei due stili. Ad esempio, funzioni che
interagiscono a livello medio basso con l'hardware o con l'OS
probabilmente risultano più semplici da scrivere in C, e probabilmente
non cambieranno,a meno che non cambi la piattaforma. Mentre invece il
codice di interazione con l'utente,ecc risulta molto più logico
organizzato secondo l'OOP, in my opinion! E inoltre è questa la parte di
un programma che subisce più spesso variazioni. 
Insomma, tutto dipende dalla finalità del codice che si scrive.

 ha scritto nel messaggio
news:pan.2003.02.06.22...@dominio.com...

Giusto così, tutto dipende dalla finalità...
Come dice anche Cesare, l'OOP è quasi obbligatorio quando si sviluppa in
gruppo.
;)

 IL PARADIGMA - OOP, procedurale, modulare o... un mix?
è simile alla solita domanda: "meglio java o c++"?
e si ritorna a discutere sul sesso degli angeli!
Cmq... concordo con "yes" e "Claudio"....Ciao!
__________________________________
"Ama e fai c'ho che vuoi".... 
__________________________________

 Insomma, tutto dipende dalla finalità del codice che si scrive.
Sono d'accordo con te, driver e cose del genere possono benissimo essere
scritte in C velocemente.
Ma il *core* del progetto, se il progetto e' grosso, dovrebbe isolarsi
da dettagli hw, os, gui ed a questo bisognerebbe applicare la tecnologia
ad oggetti in maniera seria.
Nei progetti reali invece ho visto solo (me tapino) codice pasticciato
anche nel core. 
E' stupefacente vedere quanta "teoria" esiste sull'argomento e quanto
poco viene applicata.
E dire che esistono gia' framework ad oggetti come ACE che si
presterebbero perfettamente al genere di progetti a cui partecipo ma che
nessuno ha il *coraggio* di usare.
Ma senza essere *troppo avanti* esistono anche delle serie di buoni
consigli di design che andrebbero seguiti per certi progetti, ma
continuo a non veder applicati (e' vero sono un po' piagnone :).
Vedi ad esempio la serie di articoli "architettura dei sistemi reattivi"
di Carlo Pescio 
http://www.eptacom.net/pubblicazioni.html
Ciao,
Cesare

 sara' buttato via e non esteso per il prossimo progetto.
Come a questo punto avrai capito, non sono assolutamente d'accordo con
te. Il paradigma deve essere scelto in base alle caratteristiche del
contesto come dici tu, ma ad un livello di dettaglio molto piu' basso
che non quello dell'intero progetto. I criteri fondamentali sono
piuttosto pochi:
- La stessa cosa deve essere fatta *sempre* allo stesso modo quindi
  se possibile con lo stesso codice.
Questo ti da un idea di quando e cosa portare a fattor comune.
- La scelta del meccanismo da utilizzare per fattorizzare la
  rappresentazione di un concetto dipende dalle caratteristiche di
  cio' che si vuole rappresentare.
Per esempio se un insieme di entita' hanno un comportamento comune, ma
non e' mai necessario scambiarle a runtime puo' essere preferibile un
approccio basato su template piuttosto che uno basato
sull'ereditarieta'.
Saper programmare bene in C++ vuol dire saper scegliere al meglio
quale costrutto utilizzare in ciascun contesto, senza cadere
nell'errore di considerare migliore in assoluto un costrutto piuttosto
che un altro.
Il testo fondamentale su questi argomenti e' "Multiparadigm design for
C++", di Jim Coplien, un po' ostico, ma validissimo.
Ciao,
Nicola

 te.
Non sei d'accordo in cosa?
Io non sono una fan dell'OO ma penso che scrivere buon codice sia
l'obiettivo primario in grossi progetti.
Questo obiettivo non e' stato raggiunto in nessun progetto a cui ho
partecipato almeno finora, sono solo dei grossi blob di codice C++ dove
si e' mischiato "finto OO" con codice "C-style" solo per pigrizia
mentale.
Spero che sarai d'accordo che simili gioielli non sono facilmente
estendibili ne semplici da manutere.
Dato che pero' sono convinto che l'OO e anche l'uso dei pattern aumenti
molto la comunicazione tra sviluppatori in grossi progetti, andro'
sempre contro chi preferisce lo "spaghetti-code artistico", anche se
sono sicuro che tu non sei tra questi.
Se invece non sei d'accordo che l'OO sia migliore della programmazione
procedurale o generica, beh in quel caso hai ragione, anche se io
rimango convinto che sia comodo quando si lavora in tanti.
Ciao,
Cesare


 rimango convinto che sia comodo quando si lavora in tanti.
Io non dico che l'OO non sia un paradigma valido; dico solo che non e'
ne universale, ne una garanzia di successo.
Ciao,
Nicola