Newsgroup: it.comp.lang.c++
Titolo: OOP: quali i difetti?

Ciao.
I pregi di una programmazione orientata ad oggetti mi sono abbastanza
chiari. Quali i difetti?

 chiari. Quali i difetti?
puoi partire da qui:
http://en.wikipedia.org/wiki/Object_oriented#Criticism
Mauro

)
Ora Naggum e' uno spettacolo da leggere, uno dei piu' grandi flamer di
Usenet. 
(qui invece se la prende con Perl:
http://www.schnada.de/grapt/eriknaggum-perlrant.html
)
Ora il punto di Naggum e' corretto, e' l'obiettivo che e' sbagliato. Lui
si scaglia contro C++, ma dovrebbe scagliarsi contro quelli che *non*
conoscono bene la programmazione ad oggetti, usano un linguaggio statico
e qualche metodologia di sviluppo "BigCorporate".
Poi figuriamoci, alcune critiche a C++ sono pure azzeccate, eh. E
ovviamente le cose le scrive cosi' estreme con puro gusto, direi.
Io posso dire che credo di avere una buona (ottima) comprensione dello
sviluppo ad oggetti. Posso anche dire che effettivamente mi rendo conto
come molti pattern "generici" siano pensati piu' per il mondo statico e
che appena si diventa dinamici perdono ragion d'essere (perche' il
codice senza pattern e' *anche* piu' semplice). Questo succede al
massimo grado in Lisp.
Questo non ha nulla a che vedere che Java o C++ possono essere, se usati
bene, degli strumenti sufficienti. Ora io in Python sono parecchio piu'
produttivo e Naggum in Lisp e' probabilmente ancora piu' produttivo. 
Ma quale e' il punto?
Un linguaggio ad oggetti con la corretta metodologia di OOD e la
corretta disciplina di OOP e' in generale un buono strumento, IMHO
*superiore* alla programmazione procedurale "grezza". Mi viene in mente
come si complicano certe faccende morti gli oggetti.
Poi diciamo anche che un linguaggio funzionale come si deve permette,
IMHO, di ragionare ad un livello di astrazione superiore. E amen... a me
la programmazione funzionale piace e la trovo grandiosa, specie con
oggetti come Scheme. Ma questo non ha nulla a che vedere con OO vs.
procedurale.
-- 
-riko

On 13 Apr, 14:09, 
r...@despammed.com
 (Enrico Franchi) wrote:

qui ho trovato qualcosa di interessante:
http://homepage.mac.com/marco_coisson/Tutorial/IntroAObjC/Versione_html/cap1.html
in cui tra le molte interessanti cose dice:
"la programmazione "ad oggetti" è migliore di quella procedurale, è
più moderna, è da preferirsi, ecc.",
 questo non è sempre e non è necessariamente vero. Come al solito,
dipende.
Se il programma che volete fare è piccolo, è più che altro una prova,
o un semplice programmino che fa un compito ben preciso e limitato,
sempre uguale, forse un linguaggio procedurale è meglio.

 - Mostra testo citato -
inoltre: ( 
http://people.na.infn.it/~lista/ProgrammazioneAdOggetti/trasparenze/02-ProgrammazioneAdOggetti.pdf
)
Programmare a oggetti…
– non velocizza l’esecuzione dei programmi…
– non ottimizza l’uso della memoria...

 
Per favore, evita di quotare righe e righe del messaggio a cui rispondi, 
se non sono necessarie.
Manlio

 sempre uguale, forse un linguaggio procedurale è meglio.
Questa e' una grossa sciocchezza. Se il programma da fare e' piccolo, il
programma sara' piccolo. Punto. Il fatto che venga risolto con un
linguaggio ad oggetti o meno e' completamente ortogonale. Non ci sono
vantaggi nell'usare un linguaggio procedurale su un piccolo progetto: di
fatto e' possibile usare praticamente tutti i linguaggi ad oggetto in
modo marcatamente procedurale.
Quello che e' vero e' che in un piccolo progetto *astrarre* non e'
necessario, e questa e' una cosa che in generale e' piu' facile nei
linguaggi ad oggetti. Il che vuole dire che il vantaggio di avere gli
oggetti potrebbe non essere completamente rilevante.
Quello che dimentica di dire e' che, di fatto, anche in cose cretine i
linguaggi procedurali di fatto vanno a costruire una visione ad oggetti
del mondo. E per cose banali, penso al concetto di FILE* di C, o al
concetto di descrittore di file di POSIX.
E queste cose le trovi anche nei linguaggi piu' procedurali. Spesso
anche le strutture dati beneficiano dall'essere gestite come oggetti
opachi. Da qui anche per progetti semplici (anzi, soprattutto per
progetti semplici) la STL di C++ ammazza tempo di sviluppo rispetto a
fare le stesse cose in C.
Questo anche se la struttura del programma risultera' pesantemente
procedurale e ben poco astratta, non compaiono inversioni di dipendenza,
etc etc etc.
Piu' avanti se ne esce con la teoria secondo cui gestire input complesso
sia una cosa che guadagna dal paradigma ad oggetti. Di fatto invece
l'input complesso guadagna nell'essere gestito con un qualche tipo di
parser. Che generalmente funziona con una logica piu' dichiarativa che
ad oggetti.
Io credo che se ci sono persone che studiano per anni per imparare a
progettare e scrivere per bene codice ad oggetti c'e' un suo perche'. Le
tecniche che si usano sono piuttosto raffinate e richiedono studio ed
esercizio specifico, allo stesso modo imparare bene Lisp, eh. E per
strutturare bene il software secondo i moderni paradigmi (con buone
metodologie di analisi, progettazione e infine implementazione) usando
appropriatamente i corretti pattern, bisogna conoscere e padroneggiare
la programmazione ad oggetti *anche* se si usa un linguaggio
procedurale. E' solo piu' difficile, perche' questioni cruciali prima
demandate all'implementatore del linguaggio ora ricadono sul
programmatore.
P.S. ti prego di quotare opportunamente. 
-- 
-riko

 trasparenze/02-ProgrammazioneAdOggetti.pdf
Ci sono diverse inesattezze e imprecisioni. Non credo abbia il quadro
completo di quello che vuole dire sviluppare ad oggetti oggi.
-- 
-riko

 nascono *apposta* per permettere al programmatore mediocre di lavorare
Ma nel senso che i linguaggi come Lisp effettuano una sorta di selezione 
naturale?
Perché non so se effettivamente in Lisp si possa essere veloci a scrivere un 
programma come in Java (anche grazie alle innumerevoli API esistenti).
Il programmatore di turno può essere anche un genio, e optare ugualmente per 
Java rispetto a Lisp.
Il C++ rientra anche in quella categoria? Oppure la gestione esplicita della 
memoria e altre cose a carico del programmatore, lo posizionano qualche 
spanna sopra i linguaggi dotati di Garbage Collector e simili? 

 spanna sopra i linguaggi dotati di Garbage Collector e simili? 
Dipende a chi lo chiedi. Non credo che a Graham C++ piaccia in misura
maggiore di Java. O se e' cosi', in modo marginale. Sicuramente gli
piace di piu' Python di entrambi. Ma non e' che Graham sia il Verbo.
Quello che lui pensa e' un parere, di una persona intelligente e
pesantemente skillata, ma pur sempre un'opinione..
Tra l'altro la gestione esplicita della memoria e' un "male necessario".
Male nel senso che e' una cosa in piu' da fare per il programmatore.
Necessario, nel senso che ci sono classi di applicazioni in cui C++ e'
ovviamente avvantaggiato proprio per questa caratteristica.
Nota anche che con le opportune librerie e disciplina riesci a ridurre
molto la complessita' della gestione della memoria. Il punto e' che e'
sempre e comunque lavoro in piu'. Java fa *sempre* la cosa *corretta*
(come Python, Lisp, etc etc etc.) C++ no. Tuttavia non sempre fra le
cose corrette avere un gc produce il codice piu' efficiente.
Sempre piu' persone ti diranno di si. Il punto e' che queste sono tutte
dispute che non credo abbiano una risposta univoca. Io uso C++
principalmente quando voglio precisamente avere accesso diretto alla
memoria e alla sua gestione, normalmente uso altro. 
-- 
-riko