chiarimenti: prog OO

[mircov]

Si, lo so che array e programmazione OO sono due cose diverse!
Per il codice io cerco sempre di migliorarlo anche mentre lo sto scrivendo e creco di renderlo il più semplice possibile da gestire e cerco di scrivere il meno possibile riutilizzando quello che scrivo e rendendolo il più generico possibile. Da quanto ho capito questo è possibile con la prg OO.

[luca200]

Originariamente inviato da mircov
Da quanto ho capito questo è possibile con la prg OO.

E' vero, ma non è vero che la prg OO sia l'unico modo per ottenerlo. Ribadisco che sto ragionando in riferimento alla programmazione web, che è un tipo di programmazione, come dicevo prima, che corrisponde al paradigma della programmazione procedurale, ovvero input-->elaborazione-->output.
La programmazione ad oggetti si è sviluppata (più o meno) in concomitanza con lo sviluppo delle interfacce grafiche, la cui gestione pone delle problematiche a cui la programmazione procedurale non è in grado di rispondere in maniera soddisfacente (in sostanza si tratta degli "eventi" di cui parlava Fabio). Questa problematica non esiste nell'ambito del protocollo http, su cui basa il web. Per questo la mia idea è che la prg OO possa risultare più comoda per chi è abituato ad usarla, ma che non sia indispensabile in questo ambito.

Per rispondere alla tua domanda, la riusabilità del codice può essere facilmente ottenuta creando dei file di funzioni standard che puoi riutilizzare ogni volta che credi. In un ambito OO queste funzioni sarebbero metodi statici.
[OT]
Il fatto che la programmazione ad oggetti faccia ampio uso di metodi statici dimostra implicitamente che l'approccio ad oggetti, da un punto di vista "filosofico", non è in grado di soddisfare tutte le esigenze della programmazione (e stavolta lo dico in senso generale). La mia idea in effetti è che la programmazione "ideale" fa un ampio uso degli oggetti, ma in un ambito procedurale, perché comunque la si rigiri, ogni applicazione ha un inizio e una fine
[/OT]

[mircov]

Vabbè. Cmq alla fine credo che col tempo capirò. Per adesso non ho volgia di approfondire più di tanto visto che è un concetto che proprio non mi vuole entrare in testa! Alla fine quello che devo ottenere lo ottengo e questo è l'importante. Grazie per le spiegazioni! Ciao ciao!

[Gianni_T]

Mi permetto di aggiungere il mio parere:

come è stato già detto, la programmazione ad oggetti è un aiuto per il programmatore e questo può tradursi in un prodotto migliore. Il fatto che lo sviluppo web spesso non necessita di grandi sforzi avvalla il concetto che la programmazione OO non sia necessaria in questo contesto. Ma i tempi stanno cambiando e crescono le realtà in cui si sente il bisogno di vere e proprie applicazioni web sostitutive di quelle desktop.
Sto lavorando da quasi un anno su un gestionale di grandi dimensioni (e pretese da parte del committente...) che conta 58 tabelle MySQL, 97 pagine diverse, 30 pagine in PDF dinamico, 15 pagine per l'amministrazione.
Utenti multilivello (presidente, dipendente, collaboratore,...) divisi in gruppi multilivello(sede centrale, sedi periferiche, centri locali) che lavorano su dati che possono essere in stati diversi (pratiche chiuse, aprete, in attesa,...)

Quando viene richiesta una pagina, il risultato sarà funzione di una miriade di condizioni o, se vogliamo fare un discorso sistemistico, sarà funziuone dello stato attuale del sistema (gestito dalle sessioni). Ed è quì che la programmazione ad oggetti da il meglio di se. Oggetti che nascono e muoiono all'interno di una pagina possono risultare si comodi ma non indispensabili. Se lo stato dell'applicazione è molto complesso, l'uso di oggetti che vengono 'svegliati' ad ogni pagina è una manna dal cielo.
Questi oggetti conoscono i dati su cui devono lavorare (non devo passarli come parametri).
Si ottengono pezzi di codice del tipo:

if($pratica->isAperta() && $utente->isResponsabile())
{
   $template->mostraPraticaCorrente();
   $log->memorizzaAccessoPraticaCorrente();
}
else
{
   $template->mostraErroreAccesso();
   $log->memorizzaAccessoNegato();
}

il numero di variabili che se ne vanno a spasso si riduce drasticamente, non si fanno errori di sovrapposizione di variabili (quante volte capita di usare la variabile $risultato per scopi diversi?). In più le funzioni classiche non possono essere raggruppate in maniera così efficace come succede per le funzioni membro.

Ma forse la cosa più bella della programmazione ad oggetti (ed anche la più complessa da sfruttare) è che ti permette di pensare "ad oggetti" che è un processo molto più "umano" per risolvere problemi complessi.

[mircov]

Ecco, credo anche io che sia così (ovviamente sempre da profano perchè continuo anon capirci un C4$$0!). E credo anche che potrebbe essermi utile se riuscissi ad usarla!!!!

[Fabio Heller]

Originariamente inviato da luca200
Gli eventi non esistono. Se togli la pressione del tasto 'stop', il cui unico risultato può essere di stroncare l'esecuzione, non c'è modo per l'utente di interagire con lo script o la servlet (di M$ non parlo perché non conosco, ma finché si ragiona in termini di protocollo HTTP non vedo cosa possa cambiare). Per questo dicevo che l'approccio OO è superfluo.
Non sei d'accordo?

Di veri eventi non ne esistono ma si può immaginare che ci siano, e programmare OOP come se ci fossero (e senza usare Javascript o Flash).
.NET (e prima ancora alcuni framework Java) ha sfruttato questo "modo di pensare" nel sistema di templating di ASP.NET, ma la stessa cosa si può ottenere con PHP (a settembre butterò giù un po' di codice su cui sto lavorando a saltoni per mancanza di tempo).
Questo è un modo per sfruttare a pieno le caratteristiche dell'OOP, ma quando l'applicazione è mediamente complessa io trovo comunque utile (non indispensabile, ma utile) ragionare in termini di classi e oggetti.
Immagino sia una questione di abitudine però mi costringe a pensare all'applicazione molto prima di cominciare a buttare giù codice, con il risultato di avere meno ripensamenti, meno modifiche incontrollate (tocco qualcosa qui e sconvolgo anche lì ...e così via).
Penso che questa sia la chiave di lettura del progressivo dilagare dell'OOP anche nel WEB..in più come ha detto Gianni, io trovo che sia soprattutto un modo comodo di pensare all'applicazione.
Certo che se mi chiedono di consegnare qualcosa di totalmente inedito per dopodomani mi metto a farlo in maniera pazialmente o totalmente procedurale ma, avendone il tempo, personalmente trovo più redditizio e lungimirante progettare a oggetti.