Non sono mai stato un gran sviluppatore OO:”OO(Object Oriented, programmazione orientata agli oggetti)”:http://www.informit.com/articles/article.asp?p=24607&rl=1 , per diversi motivi che vanno dalla guerra di religione al fatto che alcuni paradigmi dell’OO non sono mai ben riuscito a farmeli entrare in testa…
Oggi rispondendo ad un post di Alberto mi è venuto un dubbio sull’effettiva ottimizzazione di php 5 per quel che riguarda questo modo di programmare…
Per fortuna una delle mie principali scuse per non fare tutto in oop è ancora valida :)
ciauz
4 replies on “Procedurale o OOP?”
secondo me il problema delle performance è più un problema a livello di sistema che di codice. sento già i tuoni, ma ci sono pro e contro a pensarla così.
detto questo, il fatto di utilizzare php4 non esclude la possibilità di sviluppare OOP e di utilizzare XP/TDD/ecc…
“la virtù sta nel mezzo”
Nel mio piccolo penso che questa vecchia massima trovi una sua applicazione anche nella scelta del tipo di programmazione.
Voglio dire che la domanda “Procedurale o OOP?” avrà risposte diverse a seconda dei casi, ed ogni caso va valutato nella sua specificità
Al di là delle performance la programmazione ad oggetti porta dei vantaggi quando migliora la chiarezza del codice, ma se sono sufficenti 3 o 4 metodi e 5 proprietà forse scrivendo una paio di procedure è ancora più semplice da leggere.
Un ultimo pensiero, per il lavoro in team la mia esperienza mi insegna a scrivere commenti dentro il codice comprensibili per tutti, senza impazzire in lunghissime pagine di documentazione, e questo vale sia se programmiamo ad oggetti che a procedure.
In Object Oriented Software Construction c’è una tirata terribile contro le piattaforme che scoraggiano l’uso di alcune tecniche per motivi implementativi, e che imo è giustissima.
D’altronde, seguendo (credo) il pensiero di Alberto, penso che i colli di bottiglia raramente siano in una organizzazione del codice, e poi si fa sempre in tempo a “denormalizzare” se ce n’è bisogno, mentre per riorganizzare un cattivo design ci vuole parecchia fatica.
E poi a mio parere sviluppare OO non significa trasformare in una classe tutto tanto per il gusto di farlo, infilare singleton e variabili di classe qua e la (penso al codice di xoops) etc..
PS
al link-scusa il codice ruby “procedurale” è un ottimo esempio di programmazione ad oggetti, con tanto di design pattern ;)
@maurizio: anche io penso che la virtù sta nel mezzo e condivido quello che tu dici.
@riffraff: intendi giusto. a un certo punto, se si arriva ad un “livello enterprise”, molti produttori (anche opensource!) consigliano l’installazione di un acceleratore/cacher a livello di sistema (eaccelerator, ZendPlatform, ecc). credo che piuttosto che farsi 1k pippe su ottimizzare uno step, conviene pensare di sviluppare in modo agile, in maniera da poter cambiare velocemente il codice senza “rompere” troppo e per star dietro ai cambi di requisiti che impone il cliente. se ci sono problemi di performance, si può sempre farsi pagare per un tuning/ottimizzazione… ;-)