Newsgroup: it.comp.programmare
Titolo: Object Oriented e Procedure Oriented

In un altro newsgroup (comp.programming) una semplice domanda ha scatenato
una sequenza di risposte che mi hanno lasciato interdetto in quanto
denotavano (a mio parere) una certa confusione sull'argomento. Mi piacerebbe
sapere cosa ne pensa questo gruppo.
La domanda era:
"Perche' la programmazione Object Oriented e' considerata migliore della
programmazione Procedure Oriented?"
Ciao, Davide.

Luppoli Davide wrote:

   E` una domanda decontestualizzata e, pertanto, senza senso. Se la 
contestualizzi, per esempio aggiungendo gli incisi "nello sviluppo di 
applicazioni di dimensioni significative" o "per il riuso di codice gia` 
scritto" o, ancora, "nella progettazione mediante strumenti quali i 
pattern", allora assume un significato diverso e porta con se` anche la 
risposta. ;)
-- 
Alla prossima,
Marco

Un linguaggio orientato agli oggetti č molto piů potente perchč a differenza
della progrmmazione strutturata non č il codice che influenza
l'organizzazione dei dati bensě il contrario: sono i dati a stabilire quali
sono le operazioni che possono essere eseguite.
Mi spiego: senza l'uso degli oggetti si č costretti a modellare i dati che
vogliamo maneggiare in funzione della struttura del nostro codice.
Gli oggetti permettono di pensare i dati come qualcosa di piů intuitivo.

 della programmazione Procedure Oriented?"
come ha gia` risposto Marco la domanda posta in questo modo non ha una 
risposta significativa.
Per alcune tipologie di applicazioni un approccio procedurale puo` 
essere piu` vantaggioso che non un approccio OO; viceversa ci sono degli 
ambiti in cui e` vero il contrario.
In generale direi che l'uso *corretto* delle metodologie OO porta ad 
avere codice piu` manutenibile, riusabile, estendibile. Pero` bisogna 
vedere se il gioco vale la candela: applicare correttamente i principi 
dell'OO non e` una panacea, in quanto potrebbe richiedere un maggiore 
sforzo iniziale (sia in termini di tempo che di denaro).
just my 2 eurocent...
ciao Anto
-- 
Antonio Cuni, 20 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

...

La programmazione a oggetti garantisce una maggiore estensibiltà del
codice potendo aggiungere funzionalità con la semplice aggiunta di
metodi e/o con la creazione di sottoclassi personalizzate. Permette un
facile riuso del codice anche da parte chi non lo ha sviluppato
dall'inizio fintanto che permette di concentrarsi sui risultati e non
sul come li si ottiene.
Però genera, a parità di compiti svolti, eseguibili più grandi.
La programmazione funzionale dà eseguibili di dimensioni minori ma una
aggiunta di funzionalità può significare una profonda riscrittura del
codice. Che può non essere facile per chi non ne ha seguito lo
sviluppo.
Personalmente credo che nessuno dei due paradigmi sia migliore
dell'altro ma che tutto dipenda da cosa si deve fare, grossi progetti
il cui sviluppo dura a lungo o piccoli programmi da fare in fretta, e
da come li si fa, in gruppo o singolarmente.
Però preferisco la OO (ma è un punto di vista personale).
Saluti

 La programmazione funzionale dà eseguibili di dimensioni minori 
Non c'e' nessun legame tra la "programmazione" in quanto tale e
la dimensione di un eseguibile.  La dimensione di un eseguibile
e' determinata da moltissimi fattori.  
E' determinante l'ambiente di sviluppo che utilizzi, ma non ci
sono motivi per credere che un ambiente di programmazione a 
oggetti produca necessariamente eseguibili piu' grandi di uno
basato su programmazione procedurale.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

...

La tua osservazione e' giusta; pero' e' anche vero che i compilatori
di linguaggi che implementano i concetti della programmazione a
oggetti introducono un overhead di strutture per gestire
l'ereditarieta', l'incapsulamento, il polimorfismo, le protezioni etc.
che riducono in generale le possibilita' di ottimizzazione spaziale e
temporale del codice.
Gira in rete un ottimo tutorial di Schreiner sull'utilizzo dei
concetti della programmazione ad oggetti in C, e si capisce come ogni
struttura di dati, comunque piccola, ha bisogno di tutta una serie di
informazioni addizionali che sicuramente ne ingrandiscono
l'occupazione di memoria, ma ne condizionano anche la velocita' di
esecuzione.
Rimane quindi l'osservazione iniziale per cui, in ogni contesto, un
tool e' migliore di un altro solo in funzione di cio' che se ne fa.
saluti
Luca

 temporale del codice.
Dimostramelo.
Questo e' un mito che vige da molto tempo ma che nessuno e' in 
grado di dimostrare.  Non c'e' alcun motivo per cui un programma
OO debba essere piu' esteso di uno non OO.  Le "protezioni" non
vengono affatto gestite a run-time, sono costrizioni legate *solo*
alla fase di compilazione.  L'incapsulamento e' solo un modo diverso
di vedere le stesse cose che scrivi in modo procedurale e non ha
bisogno di introdurre strutture aggiuntive.  
L'unico punto a sfavore di un linguaggio OO (relativamente SOLO alle
prestazioni e alla lunghezza di un eseguibile) potrebbe essere il
polimorfismo e l'RTTI.


polimorfismo e l'RTTI.
Il polimorfismo però non sei obligato ad usarlo in una parte di codice
in cui hai bisogno delle massime velocità e l'RTTI generalmente si può
disattivare nelle opzioni del compilatore.
-- 
Marco Barisione (ICQ 84277092)

 disattivare nelle opzioni del compilatore.
L'RTTI e' sicuramente meno utilizzata del polimorfismo.
E' praticamente impossibile fare a meno di quest'ultimo, invece, 
se la propria applicazione sfrutta una libreria di classi (vedi
la VCL/CLX con Delphi o MFC, ecc... ecc...).


la VCL/CLX con Delphi o MFC, ecc... ecc...).
Ma onestamente quando uno usa le MFC o simili ha davvero bisogno di
una velocità tale da non permettersi l'uso del polimorfismo? Quanto è
in un progetto medio il codice che ha bisogno di tale velocità? Se
studi dicono che per un programma medio l'80% si può scrivere in
linguaggi più lenti del C++ come Python senza grandi problemi di
prestazioni allora quale è la percentuale che si può scrivere in C++
permettendosi il "lusso" del polimorfismo?


 polimorfismo e l'RTTI.
Ma l'RTTI non e' un concetto generale che puo' essere teoricamente 
implementato da qualsiasi compilatore per qualsiasi linguaggio ?
A questo punto mi sfugge perche' il polimorfismo dovrebbe introdurre
overhead, in fondo anch'esso viene gestito dal compilatore.
saluti

...

Ditemi se sbaglio nel sintetizzare la questione nel modo che segue:
l'appesantimento del codice (in termini di occupazione e velocita' di
esecuzione) e' dovuto essenzialmente alla necessita' di disporre di
informazioni a run-time sui dati (oggetti) attivi della nostra
applicazione; ma questa possibilita' NON e' intrinseca al paradigma di
programmazione ad oggetti.
Pero' negli ambienti di sviluppo piu' attuali (che sono per la maggior
parte OO ) si tende a introdurre la possibilita' di disporre a runtime
di quante piu' informazioni possibili sugli oggetti in esecuzione.
Quindi, se nello scrivere un compilatore per un linguaggio OO, ci si
limita a rappresentare gli oggetti come le struct del C, e gestire i
metodi ed il polimorfismo con chiamate ad opportune funzioni ( tutto a
carico del compilatore ) non si manifesta overhead nel codice
compilato.
In altre parole, la maggiore espressivita' e potenza di modelling
della programmazione OO pesa sulla scrittura del compilatore, e non
sul codice prodotto. Giusto ?
ciao
luca