Programmazione OOP .... ma è utile ?

[MinottoMatteo]

Originariamente inviato da Hysoka
perche secondo me tu non sei entrato nell'ottica della programmazione ad oggetti...Se tu usi gli oggetti come "contenitore" di funzioni, allora è ovvio che il tuo ragionamento fila. Ma le classe sono + di semplici contenitori.
La classe è un qualcosa che astrae un concetto della realtà. Tale concetto si può evolvere e roba di questo tipo.
La parte cruciale delle classi, cosa che non puoi fare in alcun modo con la programmazione procedurale di php, è quello dell'ereditarietà. Ti assicuro che è una cosa fondamentale, soprattutto quando devi andare a creare una struttura che può essere evoluta con il tempo, senza andare a toccare quello che hai fatto tempo prima.
Se tu dici "io ho metodi-> funzioni, ma perché devo fare la classe"?
Te lo spiego subito (magari in php non si capisce bene, ma in java acquisirebbe + senso).
Tu puoi fare una classe generica chiamata DBLayer, e magari fare due sottoclassi DBMySQL e DBPostgres.
Il punto cruciale degli oggetti è proprio qui! Perché tu puoi fare DBMySQL e un tuo collega DBPostgres. Tu non sai il tuo collega come farà la sua classe, ma di sicuro avrà i metodi che ha la superclasse DBLayer.. Partendo con quest'ottica, si sbaglia veramente poco!

Ciao,

ti assicuro che non era la prima volta che mi cimentavo con gli oggetti. Cosa sia la OOP lo sapevo anche se ammetto molto più in linea teorica che pratica e su questo non posso certo darti torto. Cosa sia una classe (ovvero più che un semplice contenitore di funzioni->metodi) non mi è un concetto del tutto sconosciuto come anche ereditarietà, poliformismo e via dicendo e anche la concezione di astrazione della realtà mi era già nota; è indubbio che se c'è un problema è molto meglio concentrarsi su un singolo elemento che stravolgere tutto il codice, come nella vita reale se c'è un problema su un piccolo scaffale di un supermercato (classe o metodo che sia) è sufficente ovviare a quello senza toccare il resto e non è necessario buttare tutto per identificare il problema.

Nonostante questo però in campo PHP mi manda nel pallone pensare ad un tipo di programmazione che mi costringe a scrivere il triplo se non di più rispetto a quella procedurale per poi arrivare allo stesso identico risultato.

[MinottoMatteo]

Originariamente inviato da arkus
buon giorno MinottoMatteo,
Prova a pensare ad un caso base, hai un tot di utenti, ognuno dei quali con tot caratteristiche (nome,cognome,età..ecc)
non facendo uso degli oggetti come ti muoveresti per rapressentare tanti utenti?
Grazie agli oggetti rimane tutto pulito e ordinato, senza variabili globali.
Senza addentrarsi in cose tecniche, questa fu la prima cosa che notai, a suo tempo, appena mi parlarono della OOP durante un corso universitario.
I vantaggi possono essere tanti nel caso si stia lavorando ad un progetto complicato, ad esempio estensibilità e modularità, ma non penso che sia sempre necessario utilizzare le classi.

buongiorno a te,

il punto che mi ha distolto dalla programmazione OOP è risolvere un problema come quello da te descritto.
Mi sono trovato a dover gestire un tot di dati provenienti dal database e nonostante una classe per la gestione del db penso ben scritta, una per il rendering a video dei dati e tutto il resto non mi è stato assolutamente possibile farlo perchè la classe, dopo essermi autenticato nel mio piccolo progetto, nella index.php neanche era presente nel senso che era come se non fosse mai stata instanziata pur essendolo.

In pseudo codice

// index.php

require_once 'autoloadClass.php';
$db = new DBLayer();

if ( se presente la sessione del admin )
{

       go->resultPage

       } else { 

mandalo alla form di login (la quale form rimanda al metodo della classe che autentica l'admin e gli piazza pure la sessione per poi ritornare alla index.php)
} 

Se l'autenticazione va a buon fine ritorna alla index.php che rinstanzia la classe, ricontrolla la sessione (che questa volta c'è) e manda alla pagina dei risultati dove è presente una cosa di questo tipo:

$sql = "SELECT * FROM tabella";
$result = DBLayer::dbQuery ( $sql );
echo "<table <!-- vari parametri + le varie formattazioni tr e td necessarie>";
while ( $row = DBLayer::dbFetchArray ( $result ) )
{

           /** Varie istruzioni per formattare la stampa dei risultati */

}
echo "</table>"; 

Il risultato sconfortante è che non solo non stampa nessun risultato ma la query neanche viene sottoposta perchè appunto la classe non esiste neanche pur essendo stata instanziata e inclusa con autoload.

[MinottoMatteo]

Originariamente inviato da Santino83_02
Io più che porre la domanda che poi inevitabilmente scatena la mega discussione tra fan club, proverei a programmare in oo e a capire da solo perchè oo e non procedurale. Poi in ogni cosa ci sono i pro e i contro, così come in un progetto non si sceglie 1 linguaggio per tutto, ma ogni parte del progetto userà le tecnologie più opportune per svolgere il compito. Che ne so, dal java per l'applicazione server al perl per l'elaborazione di file di testo al php per il web allo shell per l'integrazione con l'os ai linguaggi di markup etc

Non mi sembra ci sia in corso nessuna mega discussione tra fan club

Agli oggetti programmo da qualche tempo, almeno ci provo, e me li sono anche studiati però i casi sono due:

1) Non fa per me al punto che è molto meglio se torno alla programmazione procedurale; tra le altre essendo solo un appassionato e non un professionista non ho neanche tutte queste necessità.

2) C'è qualcosa che nonostante i libri non comprendo; il bello è che non so cosa dato che mi pare di fare tutto in modo corretto anche se alla fine non funziona mai niente e la cosa inizia anche ad essere abbastanza frustrante.

[bstefano79]

bhe in effetti php non è che sia il linguaggio giusto per capire i vantaggi dell'oop che sono innumerevoli

ma a parte PHP, i vantaggi della OOP sono innegabili: chiaramente tutto si può fare anche senza, tutto si può fare anche in C e anche in assembly, ma un linguaggio orientato agli oggetti rende la vita estremamente più semplice offrendoti un gran numero di meccanismi sintattici che ti permettono di ridurre molto il codice che scrivi. in sostanza vedila in questo modo: il compilatore ti offre altri meccanismi sintattici che puoi sfruttare e che i linguaggi non orientati agli oggetti non offrono.

l'esempio che cito sempre quando faccio questo discorso è quello delle funzioni virtuali, che costituiscono un sistema di puntatori a funzioni.
in un linguaggio OO puoi realizzare complesse gerarchie di classi, ciascuna con molti metodi virtuali e molti override, mentre per realizzare la stessa cosa in C dovresti o riempire il codice di selection statements (grossi switch, catene di if, e porcate a non finire) o reimplementarti da solo il tuo sistema di puntatori a funzioni (ti perderesti in mezzo agli asterischi ); in entrambi i casi il codice diventa molto più grosso.

l'esempio dell'incapsulazione invece (ovvero il fatto che certi campi siano incorporati in un oggetto passato come parametro implicito a tutte le funzioni che lavorano su quei campi) è un meccanismo che ti permette praticamente di eliminare un parametro ad ogni funzione che scrivi; sembra una sciocchezza, di certo è un esempio molto meno eclatante del precedente, ma quando lavori su progetti grossi e arrivi a ritrovarti funzioni con 10 (dieci) parametri t'assicuro che conta anche quello

[MinottoMatteo]

Originariamente inviato da bstefano79
bhe in effetti php non è che sia il linguaggio giusto per capire i vantaggi dell'oop che sono innumerevoli

ma a parte PHP, i vantaggi della OOP sono innegabili: chiaramente tutto si può fare anche senza, tutto si può fare anche in C e anche in assembly, ma un linguaggio orientato agli oggetti rende la vita estremamente più semplice offrendoti un gran numero di meccanismi sintattici che ti permettono di ridurre molto il codice che scrivi. in sostanza vedila in questo modo: il compilatore ti offre altri meccanismi sintattici che puoi sfruttare e che i linguaggi non orientati agli oggetti non offrono.

l'esempio che cito sempre quando faccio questo discorso è quello delle funzioni virtuali, che costituiscono un sistema di puntatori a funzioni.
in un linguaggio OO puoi realizzare complesse gerarchie di classi, ciascuna con molti metodi virtuali e molti override, mentre per realizzare la stessa cosa in C dovresti o riempire il codice di selection statements (grossi switch, catene di if, e porcate a non finire) o reimplementarti da solo il tuo sistema di puntatori a funzioni (ti perderesti in mezzo agli asterischi ); in entrambi i casi il codice diventa molto più grosso.

l'esempio dell'incapsulazione invece (ovvero il fatto che certi campi siano incorporati in un oggetto passato come parametro implicito a tutte le funzioni che lavorano su quei campi) è un meccanismo che ti permette praticamente di eliminare un parametro ad ogni funzione che scrivi; sembra una sciocchezza, di certo è un esempio molto meno eclatante del precedente, ma quando lavori su progetti grossi e arrivi a ritrovarti funzioni con 10 (dieci) parametri t'assicuro che conta anche quello

Mi fermo qua.

In definitiva forse hai ragione tu quando dici che PHP non è il linguaggio giusto per apprezzare i vantaggi della OO poi è anche vero che non sono un professionista ma un semplice appassionato di pc e programmazione quindi forse mi mancano anche le motivazioni, o semplicemente logica e abitudine, per vederla in modo "costruttivo".

Non è mia abitudine esprimermi per assoluti quindi non dico certo che la OO anche su PHP sia inutile perchè chiaramente non lo è oltre al fatto che non mi permetterei mai di asserire una cosa simile in mezzo a persone che ne sanno molto più di me e la usano quotidianamente. Dico solo che pur continuando a studiarla, anzi a questo punto studicchiarla, per ora mi arrendo e quando mi tornerà voglia di scrivere due righe lo farò in modo procedurale sperando di non venire clamorosamente smentito.

Un saluto e auguroni a tutti.

[Santino83_02]

Originariamente inviato da MinottoMatteo
1) Non fa per me al punto che è molto meglio se torno alla programmazione procedurale; tra le altre essendo solo un appassionato e non un professionista non ho neanche tutte queste necessità.

sicuramente è un modo di programmare che richiede molto piu studio, molta più pratica e molta più attenzione (e righe di codice) rispetto alla procedurale. I vantaggi sono molteplici, dalla robustezza del codice alla riusabilità alla mantenibilità di quanto scritto. Su piccoli progetti forse non te ne accorgi delle differenze, anzi il procedurale potrebbe essere molto più allettante per velocità di sviluppo. Ma su progetti medio/grandi non puoi, a mio avviso, prescindere da una programmazione fatta come si deve, in oo ovviamente.

[b]Originariamente inviato da MinottoMatteo [/b
2) C'è qualcosa che nonostante i libri non comprendo; il bello è che non so cosa dato che mi pare di fare tutto in modo corretto anche se alla fine non funziona mai niente e la cosa inizia anche ad essere abbastanza frustrante.

non ho capito

[MinottoMatteo]

Originariamente inviato da Santino83_02
sicuramente è un modo di programmare che richiede molto piu studio, molta più pratica e molta più attenzione (e righe di codice) rispetto alla procedurale. I vantaggi sono molteplici, dalla robustezza del codice alla riusabilità alla mantenibilità di quanto scritto. Su piccoli progetti forse non te ne accorgi delle differenze, anzi il procedurale potrebbe essere molto più allettante per velocità di sviluppo. Ma su progetti medio/grandi non puoi, a mio avviso, prescindere da una programmazione fatta come si deve, in oo ovviamente.

Infatti non sto dicendo sia inutile, tutto il contrario, speravo però fosse un pò più semplice, inteso come impegno, dato che alla fin fine ripeto che per me è una passione e apparte rari periodi come questo delle ferie di Natale non ho neanche il tempo per mettermi a cercare eventuali soluzioni, consigli, suggerimenti e via dicendo quando qualcosa va storto (errare umanum est) dato che riesco a dedicarmi a tale passione si e no un'oretta la sera dopo cena (tipicamente prima di crollare dal sonno ) quindi sarebbe meglio se le cose che provo a fare funzionassero in modo immediato e senza troppi intoppi mentre in questo periodo, diciamo dalle fine di novembre quando ho preso quel libro di cui parlavo, purtroppo mi è capitato tutto il contrario.

Giusto per fare un esempio dopo aver studiato i modificatori d'accesso mi è capitato di dichiarare degli attributi come privati e non riuscire ad accedervi nonostante, come da manuale, utilizzassi un metodo del tipo setQuelCheE'(); e per assegnargli un valore e getQueCheE'() per recuperare tale valore; intendevo questo quando dicevo che non mi funziona mai niente.

Sicuramente è colpa mia non lo metto in dubbio; pazienza.

[bstefano79]

Originariamente inviato da MinottoMatteo
Giusto per fare un esempio dopo aver studiato i modificatori d'accesso mi è capitato di dichiarare degli attributi come privati e non riuscire ad accedervi nonostante, come da manuale, utilizzassi un metodo del tipo setQuelCheE'(); e per assegnargli un valore e getQueCheE'() per recuperare tale valore; intendevo questo quando dicevo che non mi funziona mai niente.

Sicuramente è colpa mia non lo metto in dubbio; pazienza.

gli attributi devono essere privati mentre i metodi get e set devono essere pubblici altrineti non vi accedi

[deleted_29]

la domanda è interessante, provo a dare la mia risposta

1) php è tutto tranne un "vero" linguaggio (ok, niente fanboy, niente guerre di religione, pliz!). E' una sorta di superscriptone pompato, e quindi niente di strano che sia procedurale con "qualche" aggiunta OO "che fa fico"

2) OO, come tutte le cose, ha pregi e difetti. Per apprezzarlo occorre, tipicamente, essere costretti ad usare linguaggi OO "veri" (diciamo "puri"), Smalltalk ad esempio

3) Nel caso della progettazione di un nuovo software, OO ha ragione di esistere, principalmente, se si parte nel modo accademico, ossia modellazione UML e via cantare

4) Nel caso più comune di applicazioni con interfaccia grafica è "normale" avere un forte substrato OO per modellare le classi che vengono utilizzate, e tante piccole procedure appiccicate ai bottoni (l'ho banalizzata, ma spero si capisca)

5) Non va mai dimenticato che OO non è il nirvana, esistono ad esempio paradigmi del tutto diversi e in certi casi di potenza espressiva smodatamente maggiore (prolog & lisp, ad esempio)

----
E' un po' (ecco il parallelo ardito) come usare linux dentro una macchina vituale di windows o come installazione a se' stante.
Nel primo caso quando non si sa fare qualcosa... si usa windows
Nel secondo si è costretti a risolvere il problema con linux.

E' stato il buon stroustrup a fare il patatrac col (bastardissimo) C++

PS spero che il tono rimanga costruttivo, le mie sono umili considerazioni di uno scribacchino

[Santino83_02]

Originariamente inviato da franzauker
1) php è tutto tranne un "vero" linguaggio (ok, niente fanboy, niente guerre di religione, pliz!). E' una sorta di superscriptone pompato, e quindi niente di strano che sia procedurale con "qualche" aggiunta OO "che fa fico"

ottima definizione

Originariamente inviato da franzauker
Smalltalk ad esempio

ma perchè veramente programmano in Smalltalk? io pensavo che fosse solo accademico o qualcosa di vetusto rimasto solo nei libri

Originariamente inviato da franzauker
3) Nel caso della progettazione di un nuovo software, OO ha ragione di esistere, principalmente, se si parte nel modo accademico, ossia modellazione UML e via cantare

l'uml è superiore all'oo, tutta l'analisi del problema prescinde dall'implementazione o il linguaggio, quindi resta valido anche in linguaggi procedurali

Originariamente inviato da franzauker
4) Nel caso più comune di applicazioni con interfaccia grafica è "normale" avere un forte substrato OO per modellare le classi che vengono utilizzate, e tante piccole procedure appiccicate ai bottoni (l'ho banalizzata, ma spero si capisca)

Originariamente inviato da franzauker
5) Non va mai dimenticato che OO non è il nirvana, esistono ad esempio paradigmi del tutto diversi e in certi casi di potenza espressiva smodatamente maggiore (prolog & lisp, ad esempio)

prolog è spettacolare.

Originariamente inviato da franzauker
E' un po' (ecco il parallelo ardito) come usare linux dentro una macchina vituale di windows o come installazione a se' stante.
Nel primo caso quando non si sa fare qualcosa... si usa windows
Nel secondo si è costretti a risolvere il problema con linux.

il fanboy linux ti fa l'esempio al contrario :P