3Likesoppure con troppa calma, visto che lo faccio nel tempo libero ;-)Originariamente Scritto da Antonio
Si vede che non ti ci sei mai messo con calma
ah ah, no guarda, non sono un evagelista dei design pattern
Benvenuto nella nostra community, registra un account gratuito ADESSO!
Oltre 7000 persone hanno già registrato il loro account.
Chiedi aiuto, conversa con aziende ed esperti del settore webhosting italiano.
Iscriviti subito! In meno di 2 minuti!
LinkBack URL
About LinkBacks
oppure con troppa calma, visto che lo faccio nel tempo libero ;-)Si vede che non ti ci sei mai messo con calma
ah ah, no guarda, non sono un evagelista dei design pattern
Onestamente penso che certe critiche alle metodologie OO ed ai linguaggi OO in generale siano il frutto di quel "ricettario da incompresi" che furono (ma lo sono ancora ?) i design patterns.
Le metodologie OO consentono di dire che anche i linguaggi funzionali sono oggetti che espongono proprietà e metodi.
Varrà anche il viceversa ?
Lo sviluppo C/S è uno sviluppo OO indipendentemente da come lo si voglia approcciare. A mio avviso è più plausibile parlare di potenza espressiva degli strumenti di sviluppo che abbiamo oggi.
Why Object-Oriented Programming Is Great - From an FP Fanatic :: IOTTMCO
ok ecco che ritornano gli unit test come motivazione principale
beh non so se sia solo questione di abitudine o per i tipi di progetto che facciamo o altro, comunque i test automatici non li facciamo, questo vuol dire che manca la motivazione principale per fare OOP?
(in realtà di OOP i due programmatori ne fanno molta, questo ci tengo a precisarlo, sono io che non mi ci trovo benissimo)
Non che prima di questo thread non mi fossi mai interessato all'OO. Mi limitavo semplicemente alla sua comprensione perchè sempre più spesso, volente o nolente, ci si ritrova ad interagire con esso. Per il momento continuo con il procedurale ma sicuramente il mio prossimo progetto sarà in OO fosse anche solo per un hello world.
Molto tranquillamente ho iniziato a studiare l'OO. Sono passato per i metodi, proprietà, public, const, new, this, construct, destruct (sono proprio agli inizi). Arrivato al destruct mi sono detto "Ok, OO tutta la vita". Nella lotta procedurale vs OO prima non mi esprimevo perchè ancora legato troppo al primo. Ora però non vedo un solo motivo per il quale si debba preferire il procedurale all'OO fosse anche per il progetto più insignificante.
Il solo dubbio che mi resta riguarda l'efficienza che è per me la cosa più importante. Preferirei programmare nel modo meno "ergonomico" possibile in funzione dell'efficienza ben lieto di sorbirmi tutti impazzimenti per le modifiche e i debug. Approfondirò.
Ultima modifica di revhosting; 22-07-2012 alle 14:54
ci saranno sviluppatori più "ottimizzati" nello scrivere e gestire codice OO di me, ma per la stragrande maggioranza dei progetti al momento l'"overhead" che si porta dietro l'OOP è troppo...
valutazione assolutamente personale, ovviamente
tra l'altro comunque normalmente vengo affiancato a uno o due sviluppatori PHP che usano OOP e non ci metto becco
Concordo con TheVice, secondo me l'overhead "mentale" lo senti perché non sei abituato all'OO, perché personalmente anche su progetti piccoli l'OO mi fa risparmiare un po' di lavoro. Mal che vada scrivi un po' di più codice, ma molto più chiaro, quindi risparmi avendo codice più mantenibile.
Ovviamente hai anche un po' di overheard computazionale a causa del supporto runtime pesantuccio, ma quel overhead è molto ma molto inferiore all'overhead portato del fatto di usare PHP (o un qualunque altro linguaggio interpretato).
parlavo di quello mentale, ovvio che in ambito web in genere l'altro overhead è praticamente ininfluente
Io l'overhead ce l'ho quando devo usare la procedurale, perché ogni volta devo controllarmi quale funzione usare per modificare un set di dati.
Con l'OO è tutto più lineare: devo modificare i dati X:
X = new XClass(....);
X.doAbc();
E non devo preoccuparmi di come passare i dati alla funzione, perché se ho istanziato bene la classe sarà il metodo a sistemarsi i dati come meglio crede.
la differenza con
X = doAbc($data,$options);
sarebbe?
aggiungi appunto solo l'overhead di dover definire la classe, ossia il dominio delle funzioni (metodi di quella classe) e doverla istanziare (ok non sempre)
Che devi leggerti la doc su come passare i dati alla funzione, se devi applicare più operazioni su un set di dati devi eventualmente presentare i dati in maniera diversa e rielabolarli prima di applicarla.la differenza con
X = doAbc($data,$options);
sarebbe?
Se poi devi scrivere tu la funzione, devi fare i check sui dati in ingresso per ogni funzione, mentre con una classe lo fai una ed una sola volta quando scrivi il costruttore.
Insomma, è tutto un altro modo di lavorare...
seeee vabbè ma io sto parlando di talmente poche righe di codice che non conviene manco perdere il tempo di scriverci la documentazione, cioè si spiega da solo basta leggerlo, ovvio che i nomi delle funzioni devono essere capibili e sensati
sto parlando di chessò, massimo 10-15 functions per un sito, un centinaio di righe di codice, la maggior parte del codice di un sito è di presentazione (html, css, js...)
magari 50 pagine "statiche" e una sezione news, robe così
copio il codice php cambio quelle 10 righe che servono per quel sito specifico e ho codice ottimizzato per quel sito senza l'overhead di dover pensare a generalizzare classi, oggetti, metodi, proprietà ( che comunque non vanno mai bene così come sono e ci devi continuamente rimettere le mani)
ovvio che non tutti i nostri lavori sono così, sono così quelli di cui mi occupo senza l'appoggio di programmatori PHP
il migliore codice OOP è quello che fanno gli altri
mica ho capito
per esempio hai un array con i risultati di una query come $data, e come $options gli puoi passare tutte le configurazioni che vuoi per l'output...
a parte che codice del genere comunque lo metterei nelle "view" ( che seguendo la filosofia php comunque sarebbero fatte con PHP: Output Control Functions - Manual ) e non farei manco una function, quindi sto sbagliando esempio
non so fammi un esempio tu, senza un esempio pratico non mi ci raccapezzo
dipende dai dati, comunque è vero su quel fronte sono troppo lazy, ma per sti sitini keep it simple
I pregi dell'OO emergono quando il codice si complica, se la cosa più complicata che devi scrivere sono due cicli for uno dentro l'altro, come spesso accade nel web developement, è chiaro che allora non ti serve e non si vede la differenza.
Per fare un esempio concreto, di recente ho integrato un server di jabber (openfire) con un sito preesistente per fare in modo che solo alcuni utenti del sito potessero usare il server, dividendo anche gli utenti in vari gruppi. Quello che mi è bastato fare è implementare un'interfaccia. Se openfire non fosse stato scritto in un linguaggio OO avrei perso 10 volte più tempo solo per capire dove andare a mettere le mani.
Se sei un creatore "seriale" di siti semplici, imho l'OO diventa comunque utile perché ti permette la riusabilità in maniera molto semplice.
Alla fine ti fai un gruppetto di classettine e le usi per avere un mini mvc (parli di view & Co, alla fine usi un mvc rudimentale) con controllo su db, sessioni & Co, poi usi solo quello che ti serve per ogni specifico progetto.
Ovvio che fare una classe per printare hello world non ha senso.
no no pochi post fa c'era gente che ha scritto che anche per l'hello world userebbe OOP
gettano le pietre e nascondono la mano
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
Permessi di Scrittura
© 2006 - 2012 WeTalk Group S.r.l.- P.iva IT04026910408
E' vietata la riproduzione anche parziale dei contenuti
Rispondi Citando
Segnalibri