
Originariamente inviata da
salvio78
Qua si sta facendo un bel casino e confrontando due linguaggi analizzandoli da aspetti diversi e usando addirirttura paradigmi di programmazione diversi.
1) OOP vs POP. La programmazione a oggetti è ostica perchè si usa un modello mentale con una tecnica che richiede il modello diametralmente opposto. Essendo il paradigma procedurale creato con una logica top-down, si è portati a risolvere il problema dall'alto verso il basso. Questo è un modo comune per un essere umano di pensare, per questo quasi tutti riescono facilmente a programmare con questo paradigma, che basa il suo punto di forza sulla conoscenza delle api del linguaggio.
Nel caso del paradigma a oggetti la logica è stravolta, poichè è un modo di pensare il problema bottom-up. Non puoi dividere il problema con approccio procedurale ma devi partire dai dati, quindi dagli attori in gioco. Non è tanto campato in aria dire che se si partisse dall'UML forse la programmazione a oggetti risulterebbe molto più intuitiva.
In genere si presta bene per grandi progetti proprio perchè non è fatta per "programmare a vista", ma per una seria pianificazione degli attori in causa e delle loro relazioni. Inoltre dato che l'approccio bottom-up, quindi creiamo prima le componenti e poi le facciamo iteragire, fa si che si possa modularizzare molto bene i pezzi di codice coinvolti nell'aplicazione, si è in passato studiato quasi ogni eventuale problema che portasse a duplicazioni e riusabilità del codice e si sono risolti con dei pattern che se analizzati aiutano a scrivere codice la cui manutenzione risulta molto facile.
Non si deve mai affrontare la programmazione a oggetti con la logica di dividere il problema in sottoproblemi, ma di dividere i dati dell'applicazione e farli iteragire.
Ora PHP fa sì che l'aplicazione possa essere spurea, ovvero con una percentuale di codice a oggetti e codice procedurale, Java impedisce totalmente questo, obbligando a utilizzare al 100% gli oggetti, ma posso garantire che se uno si impegna di brutto, riesce a scrivere una piccola parte del codice in forma procedurale anche in java.
A chi dice che le classi sono simpatiche, gli dico di provare a implementare applicazioni che hanno funzioni che cambiano di poco e a riscrivere sempre le stesse cose, questo con l'ereditarietà non succede ed è molto facile poi fare modifiche o globali o parziali.
Provate a fare due progetti uguali in procedurale e a oggetti, si fanno tranquilli, ma poi fateli crescere e si vedranno subito le differenze nella scalabilità delle due versioni.
2) PHP vs JAVA: Concordo che PHP al momento non è molto maturo nonostante si siano fatti passi da gigante, però lascitemi dire che 10 anni fa, mi sconsolò molto java con le sue servlet e le sue jsp, perchè le applicazioni erano nettamente più lente di quelle in php.
Il problema di PHP che permette di scrivere applicazione a persone che non sanno quello che fanno, ma se usato a dovere da quasi una sintasi a oggetti molto rigorosa. Ok, l'introduzione dei metodi magici e delle traits, a mio modesto parere se la potevano risparmiare, anche se le seconde se usate oculatamente, aiutano a non duplicare il codice orizzontalmente nella gerarchia di ereditarietà, però a quel punto, tanto vale fare una composizione con un oggetto terzo e si evitano problemi di lettura del codice che possono complicare notevolmente la manutenzione e il debug di un'applicazione.
Però personalmente non capisco come uno possa programmare bene a oggetti in PHP e non riuscirci in java, i concetti sono i medesimi e il paradigma implementabile egualmente.
Non comprendo come sia possibile capire un sistema di programmazione con un linguaggio e non con un altro. Anzi java ha anche l'abilità di importare facilmente altre classi dai packages, cosa che in PHP può essere abbastanza problematica. Basta guardare che Zend è stato completamente ridisegnato per passare dai pear della versione 1, dove le classi avevano dei nomi bestiali per evitare collisioni di nomi, all'autocaricamento delle classi tramite namespace nella versione 2.
A chi mi viene a dire che PHP ha solo api procedurali, dico che dice il falso perchè per esempio per gli Array e per l'IO dei File con la versione 5 si sono implementate delle classi native. Poi non credo che sia complicatissimo creare una classe Stringa o una classe Socket per usarla nella programmazione a oggetti: d'accordo non la si trova bella e pronta, ma una volta scritta uno se la conserva e la tiene come classe di libreria e la usa per un suo personale framework o da integrare con altri semmai non la mettono a disposizione.
Lo stesso Java per essere a oggetti puro avrebbe dovuto eliminare i tipi primitivi, mentre li ha mantenuti aggiungendo classi wrappers ad esmepio per i numeri interi. Non credo che il fatto che un linguaggio metta a disposizioni api o tipi procedurali possa inficiarne l'uso a ogetti, tutto sta nella discplina del programmatore e nella sua conoscenza della progettazione del software.
3) I CMS in PHP: arriviamo alla nota dolente. WordPress e Joomla sono pessimi. Magento è una cannonata ma è lento proprio perchè lo stesso Zend è un mattone. Per carità facilita lo sviluppo ma è pesante molto pesante, io non dico di scrivere codice da zero, ma vale la pena crearsi man mano le proprie librerie e il proprio framework: è vero inventare la ruota ogni volta non è possibile in una logica business e enterprise, però con il paradigma a oggetti, anche se ti rompi le palle per scrivere una cosa che con quello procedurale impiegheresti due minuti, poi ti ritrovi un blocco di codice riusabile e qua che tornando al punto uno, comprendi che nello sviluppo il paradigma a oggetti sta prendendo il sopravvento su grandi progetti, proprio per la sua estrema facilità nel creare applicazioni scalabili. I CMS purtroppo tendono con il tempo a essere progetti rattoppati con toppe di nuova tecnologia cucite su blocchi di vecchia tecnologia e il risultato lo si vede poi in face di sviluppo e manutenzione e wordpress supera tutti sotto questo aspetto.
Scusate se mi sono dilungato.