Qual è effettivamente l'utilità della prog. ad oggetti?

[JorisDorian]

Ciao a tutti
Non dubito che non ci sia un'utilità ma sinceramente non riesco ancora a percepirla...
Apritemi un po' gli occhi... sono sicuro che quando arriverò a conoscere bene l'argomento dirò "è molto migliore"... ma datemi un'anticipazione, uno stimolo per andare avanti... :-D
Cos'è che posso fare con le classi che non posso fare con una funzione normale?
Perché ragionare in "class" e non più in "function"?
Perché ad esempio dichiarare una variabile "privata" o "protetta"?... mi chiedo: perché proteggerla? Che senso ha?
Sono io che programmo, sono io che scrivo il programma in modo tale che non venga utilizzata quella variabile in altri ambiti... non ho bisogno di proteggerla...
Viene dichiarata protected in modo tale che nessuna classe esterna la utilizzi... mi chiedo: c'è per caso il pericolo che a mia insaputa un'altra classe utilizzi quella variabile senza che io lo abbia scritto?
Scrivo la classe in modo tale che non utilizzi quella variabile e basta! Che senso ha dichiararla protected?

[webmasterala]

non c'è 1 risposta è come se ti chiedi a cosa serve l'abs...

il discorso degli oggetti è stato creato piu che altro per avere funzioni e classi pronte...

[oronze]

se ragioni a funzioni NON ha possibilità di:
- riuso (fatto in maniera seria, non riusare la funzione che faccia 2+2)
- ridurre i costi di manutenzione
- eliminare problemi di cambio di specifiche
- avere una forte corrispondenza tra livello architetturale e livello di codice
- aumentare il livello l'astrazione
- chiarezza del codice
- semplicità di sviluppo
- possibilità di lavorare in team
- possibilità di sviluppare un progetto in maniera incrementale codificando prima le classi e i moduli che rappresentano un fattore di criticità per il cliente (in termini di tempo)
- effettuare test ad hoc sull'intero sistema software
etc. etc.....
è chiaro che se sviluppi un applicativo semplice semplice dove 50 righe di codice sono più che sufficienti, i vantaggi della programmazione ad oggetti non li noti nemmeno...

Pensa in grande: sviluppo di CMS, sviluppo di gestionali, sistemi per la contabilità, sistemi di schedulazione, etc.

[webmasterala]

chiaramente dipende dal listato, ormai pero ci sono tante di quelle piattaforme che nn ci si pensa piu

[Grino]

Permettimi di rispondere alle tue domande con altre domande:

Cos'è che posso fare con le classi che non posso fare con una funzione normale?
Perché ragionare in "class" e non più in "function"?

Cos'è che posso fare con un linguaggio strutturato che non posso fare con un linguaggio a spaghetti e privo di funzioni?

Perché ad esempio dichiarare una variabile "privata" o "protetta"?... mi chiedo: perché proteggerla? Che senso ha?

Perchè dichiarare una variabile all'interno di una funzione?... mi chiedo: perchè nasconderla? Che senso ha?
Sono io che programmo, sono io che scrivo il programma in modo tale che non venga utilizzata quella variabile in altri ambiti... non ho bisogno di proteggerla o nasconderla...

************************************

Adesso diamo delle risposte generiche che siano di stimolo.
Domanda uno: Perchè ragionare per classi e piuttosto che funzioni.

Premesso che entrambi gli approcci conducono alla soluzione del problema, è appunto il modo di approcciarsi al problema che cambia.

Con la programmazione procedurale tu ipotizzi un flusso del programma, quindi inizi a buttare giù delle funzioni e quindi delle strutture dati su cui tali funzioni operano. Cambiare la struttura dati può voler dire andare a caccia di tutte le funzioni che ne fanno uso oltre al dover verificare che quanlche funzione non produca effetti indesiderati rispetto ad altre funzioni.

Con le classi parti dagli oggetti del tuo programma (o almeno ci provi) andandoli a descrivere tramite caratteristiche e azioni cui l'oggetto è in grado di rispondere. Le caratteristiche sono i dati e le azioni sono le funzioni che operano su tali dati. Questa descrizione di caratteristiche e azioni costituirà la classe che utilizzi come un timbro per dare origine agli oggetti. L'oggetto è quindi una scatola nera di cui puoi anche ignorare il funzionamento interno (dati, funzioni e come le funzioni operino con i dati) ma con cui puoi interagire tramite una interfaccia definita dai dichiaratori di accesso public, private e protected. Col tempo potresti andare a modificare la classe (dati e funzioni) per rispondere a nuove esigenze. Le parti di programma che utilizzano quell'oggetto non saranno turbati se non turberai l'interfaccia cui il programma accede.

Questa è una tanto per dire, la prima che mi è venuta in mente...

Domanda due: Perchè dichiarare una variabile protected o private?
Come abbiamo detto prima la classe fornisce una interfaccia. Diciamo un punto di aderenze o contatto tra il programma, e l'uso che questo fa degli oggetti prodotti dalla classe. Ovviamente una interfaccia deve esporre solo ciò che serve, anche al fine di evitare accidentali modifiche a parte dell'oggetto, ai suoi dati, che potrebbero innescare risultati inattesi. In generale non c'è motivo per cui una classe debba esporre in modo diretto i propri dati, quindi le variabili dovrebbero essere sempre private. Anche i discendenti di una classe che in genere specializzano la classe stessa non dovrebbero accedere alle variabili del genitore ma agire sulla classe tramite i metodi (azioni... funzioni) questo sempre per garantire coerenza nel contenuto dati dell'oggetto. Al più ai discendenti si possono garantire dei privilegi ulteriori tramite dei metodi protected, che in generale al programma non interessano, ma che per un discedente possono essere fondamentali per conoscere o modificare il proprio stato, senza manomettere o correre il rischio di rendere incoerente la scatola nera prodotta dalla classe genitore o superclasse.
Un caso in cui dichiarare una variabile come protected potrebbe essere quando il mio oggetto delega alcune funzionalità ad altro oggetto memorizzato fra le proprie variabili. in tal caso poteri rendere la variabile (che contiene un oggetto) protected in modo che i miei discendenti vi accedano e lo utilizzino tremite i propri metodi. Ma anche in questo caso utilizzerei il private per la variabile. Renderei accessibile tramite metodo il contenuto della variabile in questione ed il suo settaggio, in modo da poter sempre verificare che non venga fatto un uso impoprio della variabile e non ci sia il rischio di oscillazioni nel programma.

[Santino83_02]

quoto oronze

come si dice sempre: per il sitarello più o meno piccolo puoi anche andare avanti a script e funzioni... se aumentiamo di livello, le problematiche diventano tali che solo un'adeguata programmazione ad oggetti+determinati paradigmi di programmazione e testing del codice ti permettono di realizzare il progetto e di renderlo mantenibile e sviluppabile con bassi impatti

Mi astengo dall'esempietto perchè ora non mi viene in mente nulla di sufficientemente semplice

[Ratatuia]

per una risposta breve viene da dire DRY (do not repeat yourself)

per una risposta articolata, la programmazione ad oggetti risponde alle esigenze di avere un codice ben organizzato, soprattutto su progetti particolarmente estesi.

Molti concetti potrebbero sembrare inutili e sovrabbondanti (ad esempio classi abstract e interfaces) per piccoli progettini, ma in determinate situazioni possono fare la differenza tra spendere il 99% del tempo nel risolvere bug ed errori vari invece che apportare nuove funzionalità all'applicativo.

Inoltre la programmazione ti impone di fare una suddivisione logica del tuo codice sorgente e insieme all'uso di determinati patterns (ad esempio il MVC) riesci a ottenere una organizzazione del codice ancor più definita e chiara.

inoltre se sei uno sviluppatore che lavora a più progetti, avere una solida libreria di oggetti che possono essere utilizzati su più progetti permette di ridurre il tempo per lo sviluppo di nuovi progetti e di risolvere eventuali bugs solo in un punto.

e poi andare avanti ancora all'infinito

[Ironmax]

Anche io quoto oronze.
Sto costruendo una piccola applicazione gestionale in php con programmazione strutturata, ma il codice sta andando alla deriva per conto suo, anche se cerco di mantenerlo in certi limiti e quindi ritocchini su ritocchini.