Newsgroup: it.discussioni.ingegneria
Titolo: Quesito Informatico: perchè la OOP (a tutti gli ingegneri informatici e non solo)

Ciao a tutti,
sto iniziando ad interessarmi della programmazione orientata agli oggetti
(......si solo adesso!!!!).
Essendo un novello nel campo volevo sapere se mi potete dare una mano ( vi
chiedo poche righe non di più) a capire la filosofia di questo approccio
alla programmazione; mi chiarisco:
che differenza c'è fra una programmazione di tipo procedurale con una di
tipo Orientata agli oggetti? E più in particolare che differenza c'è nel
realizzare un programma suddividendolo in sottoprogrammi tramite procedure e
funzioni (vedi pascal per esempio) e nel realizzarlo invece con un approccio
orientato agli oggetti?
Ciò che non mi è chiaro è proprio la diversa filosofia (che ci dovrebbe
essere fra queste due soluzioni se non ho capito male....) che esiste fra
questi approcci e il tipo di esigenze che hanno portato alla nascita della
OOP.
Sò che la risposta potrebbe essere lunga e complessa comunque anche poche
frasi mi aiuterebbero a chiarirmi la questione.
Se inoltre qualcuno sa dirmi dove trovare in rete appunti che mi aiutino a
capire meglio questo problema gliene sarei molto grato.
Grazie a tutti.

 OOP.
Come tu stesso hai detto la risposta č argomentabile all'infinito, 
staremmo a parlare ore, ti faccio io una domanda:
guardati intorno, vedi oggetti od operazioni? Vedi l'auto, o il 
"svoltare a destra dell'auto" ;) Ha piů senso (Non che sia meglio) 
progettare ad oggetti che proceduralmente, IMHO. Senza poi togliere 
qualla grossa mano venuta da UML.
HTH
Ciao
Giuseppe

 OOP.
Credo che non ti sia chiara semplicemente per poca esperienza :-)))
Dopo che ti sei spaccato la testa a scrivere programmi complessi (magari
architetture client/server) con linguaggi procedurali, potrai capire che
paradiso è la programmazione ad oggetti.
Certo un pò faticosa all'inizio (uno strumento più evoluto di un altro
comporta sempre il "doverlo imparare"), ma molto utile.
La fatica dipende anche dal tipo di linguaggio che usi: programmare in Java,
la maggior parte delle volte, risulta essere un paradiso rispetto al C++.
(non scateniamo guerre di religione per carità!!!)
Nel linguaggio di programmazione ad oggetti si enfatizzano alcuni discorsi
chiave della programmazione rileggendoli secondo un'ottica diversa.
La programmazione OOP non è LA SOLUZIONE, è solo uno strumento che dà alcuni
vantaggi.
Cito solo quelli che mi vengono in mente relativi alla mia esperienza Java.
In Java, rispetto ad altri linguaggi come il C++, alcuni discorsi sono stati
estremizzati per semplificare e rendere più sicura la programmazione, a
scapito dell' efficenza.
Innanzitutto in un oggetto è presente il concetto di astrazione sui dati.
Un buon oggetto potrebbe rappresentare, innanzitutto, un tipo di dato che ha
una sua valenza logica nel progetto.
Ad esempio, se nel progetto è prevista l'anagrafica degli utenti, con un
oggetto potresti rappresentare quei dati significativi per l'utente.
Non pensare ad un oggetto come ad un estensione dei record. Negli oggetti
possono essere presenti dati arbitrariamente complessi. L'intero programma
stesso è un oggetto.
L'accesso a questi dati in genere non avviene direttamemente, bensì
l'oggetto fornisce dei metodi per l'accesso ai dati.
In questo modo puoi realizzare un oggetto che rappresenta un dato astratto,
corredato delle funzioni di accesso ai dati.
Si possono, inoltre, definire oggetti composti da altri oggetti, o oggetto
che specializzano il lavoro di altri oggetti.
Oltre a questo puoi inserire all'interno dell'oggetto, tutti quei metodi che
efettuano operazioni sull'oggetto stesso e/o insieme ad altri oggetti.
L'utilizzo dei dati in un oggetto, quindi, non avverrà tramite una
"procedura del programma" che accede direttamente ai dati, li elabora e li
ripone direttamente nelle aree di memoria, bensì l'oggetto presenterà al suo
esterno tutti e soli i metodi che il progettista ha ritenuto sufficenti al
suo utilizzo.
Importare certe "funzioni" in un programma, quindi, non significherà più
aggiungere librerie e funzioni, ma importare ed utilizzare determinati
oggetti.
Capiamoci: all'interno di un oggetto esistono mini programmi procedurali, ma
questi mini programmi hanno uno scope ben limitato su un insieme ben
definito di dati mascherabili all'estero dell'oggetto.
Una volta compilato, poi, diventa una sequenza di istruzioni assembler,
figuriamoci dove va a finire la strutturazione ad oggetti. Se poi viene
eseguito da un processore superscalare allora viene meno anche l'ordine di
esecuzione delle istruzioni, ma questo è un'altro discorso ;-)
Con oggetti ben strutturati (ed un linguaggio di programmazione come Java)
il side effect dovrebbe essere l'ultima cosa a cui deve pensare un
progettista.
Un altro vantaggio è la forte tipicizzazione dei dati. Con alcuni linguaggi
di programmazione (ad esempio pascal) puoi creare un array di caratteri per
rappresentare una stringa. Ciò che distingue una stringa da un array di
caratteri è solo l'utilizzo che ne fai. Nulla ti vieta di utilizzare la
stessa struttura per implementare una coda o una pila.
In questo modo, nessuna struttura dati ha in se le caratteristiche del tipo
dati che vuole rappresentare.
Paradossalmente, per tornare all'esempio di prima, un progettista potrebbe
sbagliare nome a due variabili e usare su una stringa le stesse funzioni che
utilizzerebbe sull'aray di caratteri senza creare traumi al compilatore.
In un linguaggio di programmazione ad oggetti è normalmente (uso questo
avverbio a ragion veduta) impossible applicare metodi che non appartengono a
gli oggetti.
Tornando all'esempio di prima, non è possibile applicare i metodi di un
vettore ad una stringa.
In questo modo un oggetto non solo implementa un tipo di dati, ma lo
rappresenta pienamente nella sua struttura e nei suoi metodi.
Un'altra estremizzazione la sia ha con l'obbligatorietà di utilizzare una
programmazione strutturata.
Spero di non aver scatenato risentimenti in nessuno :-))), parlare di
informatica su argomenti così tecnici è peggio che parlare di politica.
 Se ti stai avvicinando alla OOP con JAVA ti consiglio di leggere Thinking
in Java di Bruce Eckel. Con google lo trovi anche in rete.
'notte a tutti...
LA

 in Java di Bruce Eckel. Con google lo trovi anche in rete.
http://www.mindview.net/
Ciao
Giuseppe

 wrote in message
news:b8l3en$laq$1...@newsreader1.mclink.it...

Esiste anche "Thinking in C++" sempre di Eckel. Ho avuto modo di compararli
entrambi a quelli del padre e figlio, Deitel & Deitel, "C++ How to Program"
e "Java How to Program" e ti consiglio gli ultimi due. "C++ How to Program"
di Deitel&Deitel e' il testo che utilizziamo attualmente nel corso di Data
Structures. Il sito e' 
www.deitel.com
 .

Curiosità completamente OT: ma studi ad Austin, TX?
Giuseppe


Si. Perche'?

 
Conosco un po' di gente di Austin, la mia ex ragazza è di lì, e 
frequenta la UT...Cmq molta gente che frequenta il dipartimento 
d'italiano e francese.  Stavo pensando di fare il tirocinio da quelle parti
Ciao
Giuseppe

 capire meglio questo problema gliene sarei molto grato.
Sinceramente, lascerei perdere gli appunti in rete per la programmazione 
ad oggetti. Non rendono proprio bene l'idea. Io posso solo consigliarti 
2 bibbie del settore.
(1) Progettazione ad oggetti con UML - Meilir Pages-Jones (ovviamente 
e' la versione italiana di un testo in inglese).
(2) Design patterns - Gamma, Helm, Johnson, Vlissides (se vuoi dovrebbe 
esserci anche una versione in italiano).
Specialmente il primo e' piu' teorico e concettuale, e ti permette di 
capire cosa fai quando ti avvicinerai a qualunque linguaggio ad oggetti 
dandoti anche un'infarinatura sull'UML.