Fino al rilascio ufficiale della versione 5 di PHP, si può tranquillamente affermare che quest'ultimo era un linguaggio prettamente procedurale, nonostante la presenza di costrutti che lontanamente richiamavano i concetti della OOP.
Tuttavia, se PHP 4 è un linguaggio procedurale, lo stesso non si può affermare di PHP 5. Quest'ultima release ha portato con sé un kit di strumenti davvero completo che permette di utilizzare le tecniche della OOP all'interno degli script server-side realizzati con il linguaggio in questione. È ovviamente possibile che uno sviluppatore continui a scrivere codice precedurale anche con la versione 5 di PHP, che mantiene intatte tutte le caratteristiche della precedente versione con aggiunte davvero molto interessanti.
In questo articolo vedremo dunque i pro e i contro di entrambe le tecniche di programmazione in questione analizzando accuratamente i punti di forza delle stesse.
Codice procedurale
Il codice procedurale è un codice privo di classi ed oggetti che fa un uso massiccio delle funzioni, interne ed in particolare user-defined. I vantaggi offerti da questo modello di sviluppo sono molti.
Compatibilità. Se un'applicazione PHP è realizzata mediante codice procedurale, i possibili problemi di compatibilità sono ridotti al minimo: è possibile intercambiare la piattaforma di sviluppo dalla versione 4 alla 5 e vice versa ed ottenere i medesimi risultati. Ovviamente, bisogna essere ben consci dei possibili diversi comportamenti delle funzioni aventi stesso namespace all'interno delle differenti versioni del linguaggio, ma i più noti problemi di compatibilità sono bene elencati attraverso la documentazione ufficiale.
Facilità d'uso. È un dato di fatto: produrre codice procedurale è più semplice che produrre codice orientato agli oggetti. Questo perché il codice procedurale non richiede nessuno studio particolare, all'infuori delle basi del linguaggio e della documentazione sulle funzioni interne, cosa che non si può assolutamente affermare nel caso di codice Object-Oriented.
Quest'ultimo infatti, richiede conoscenze elevate sulle meccaniche e sulle metodologie di esecuzione, nonché su tutta la vasta gamma dei concetti in esso racchiusi. È impensabile scrivere un'applicazione OOP in PHP (e in qualsiasi altro linguaggio) senza avere esperienza in merito, dato che il risultato sarebbe un codice vulnerabile e difficilmente mantenibile.
Libertà. Questo punto è una diretta conseguenza del precedente. Se si scrive codice procedurale non si hanno molte regole da seguire: sta allo sviluppatore scegliere le sintassi, le metodologie e le tecniche di scrittura che meglio preferisce. Questa totale forma di libertà in realtà, rappresenta sia un vantaggio che uno svantaggio: molte delle accuse rivolta a PHP si riferiscono proprio a questa mancanza di regole che, parecchie volte, permette di dare vita a veri e propri "script-spazzaura", difficili da mantenere e da condividere con altri sviluppatori.
Velocità. Nella maggioranza dei casi, scrivere gerarchie orientate agli oggetti comporta più tempo sia per quanto riguarda la pianificazione della struttura che per l'effettiva mole di codice da scrivere. Senza contare le diverse ramificazioni di cartelle e script da includere risultanti. Un codice procedurale è generalmente più immediato da produrre e più veloce da scrivere.
OOP
Un codice orientato agli oggetti è caratterizzato da gerarchie di classi più o meno complesse e da una struttura modulare che prevede l'uso degli oggetti nel corso di tutta l'applicazione. Ecco i punti di forza di quest'altra tecnica di programmazione.
Mantenibilità. Il codice orientato agli oggetti permette di produrre applicazioni maggiormente mantenibili nel tempo e completamente integrabili in altre applicazioni. Grazie ai concetti di astrazione e polimorfismo e grazie alla presenza delle interfacce, gli sviluppatori possono creare vere e proprie API e condividerle con team di sviluppatori senza modificare le strutture originali.
Vasto kit di strumenti. La presenza di strutture OOP ha permesso alla versione 5 di PHP di di offrire agli sviluppatori una gamma davvero vasta di nuovi strumenti, in ogni possibile ambito. Dal parsing dei documenti XML (ora diventato estremamente più semplice) tramite le classi SimpleXMLElement e DOMDocument, all'interazione con il Database (classi MySQLi e gerarchie PDO) e con i Web Services (prime tra tutte le classi SoapClient e SoapServer per trasmettere informazioni attraverso il protocollo SOAP) fino ai costrutti nativi del linguaggio come le eccezioni, che possono ora essere generate e soprattutto personalizzate.
Presenza di regole. La presenza di regole precise può costituire un grande vantaggio per lo sviluppatore e soprattutto per gli sviluppatori abituati a lavorare in team. Ciò permette di produrre codice pulito, scalabile, condivisibile ed altamente mantenibile.
Estensibilità e modularità. Un buon codice OOP favorisce il 100% di estensibilità: è possibile aggiungere nuove o più specifiche funzionalità tramite script addizionali senza alterare le precedenti gerarchie: è questo uno dei poteri principali della Object Oriented Programming.
Prendiamo in considerazione, a scopo illustrativo, una situazione in cui abbiamo una classe base Connect che racchiude gli strumenti necessari a connetterci ad un Database ed una classe specifica ConnectToPartnerA (sottoclasse) che ci permette di collegarci al Database del nostro partner denominato "A".
Successivamente guadagniamo una collaborazione con il partner denominato "B" e vogliamo interagire con i suoi DBMS affiancando alle funzionalità che avevamo creato in precedenza nuove caratteristiche. Non occorrerà modificare le classi precedenti, ma basterà estendere la classe base Connect con funzionalità specifiche per l'interazione con il nuovo partner: in questo modo otterremo un codice modulare ed ulteriormente estensibile. Con il codice procedurale questa possibilità è pressoché impossibile, o meglio, è assai difficile da realizzare senza apportare modifiche alle strutture originali.
Design Patterns. Partiamo dalla definizione di Wikipedia: «Nell'ingegneria del software, un design pattern (struttura di progettazione) può essere definito "una soluzione progettuale generale a un problema ricorrente". Esso non è una libreria o un componente di software riusabile, quanto una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software».
Grazie alla OOP, ora possiamo adottare un'infinta gamma di Design Patterns per produrre le nostre applicazioni affidandoci ad algoritmi testati e di ultima generazione (Observer, Factory, Singleton, Builder, Prototype, Bridge, Decorator sono solo alcuni dei più utilizzati). Il pattern MVC (Model View Controller) in particolare, è una delle più recenti tecniche di programmazione che ha avuto un'evoluzione ed una diffusione impressionante nelle applicazioni e nei linguaggi di nuova generazione: Ruby e Zend Framework ne costituiscono una prova importante.
Sebbene sia possibile mettere in pratica alcuni Design Patterns anche con il codice procedurale, questa rappresenta una pratica non comune e difficile da realizzare, senza contare che i risultati non potranno sempre essere competitivi: i Design Patterns nascono per la OOP.
Esempi di codice procedurale e codice OOP
A puro scopo illustrativo, ecco a confronto due frammenti di codice PHP, realizzati con le due differenti metodologie, che permettono di ottenere lo stesso risultato (il secondo snippet potrebbe essere scritto in mille modi differenti, ma è creato appositamente per un confronto immediato con il codice procedurale):
Listato 1: codice procedurale
<?php
// stampa un tag p
function tag_p ($text, $ret) {
$txt = "<p> {$text} </p>";
if($ret) return $txt;
echo $txt;
}
// stampa un tag div contenente un tag p
function tag_div_p ($text) {
echo "<div>" . tag_p($text, true) . "</div>";
}
// stampa "<div><p> this is a message </p></div>";
tag_div_p("this is a message");
?>
Listato 2: codice OOP
<?php
class Tags {
public function tag_p ($text, $ret) {
$txt = "<p> {$text} </p>";
if($ret) return $txt;
echo $txt;
}
public function tag_div_p ($text) {
echo "<div>" . $this->tag_p($text, true) . "</div>";
}
// ...
}
$tags = new Tags();
// stampa "<div><p> this is a message </p></div>";
$tags->tag_div_p("this is a message");
?>
In conclusione
Le conclusioni che si possono trarre da questa analisi sono semplici: scrivere correttamente codice OOP è sinonimo di qualità e robustezza dell'applicazione, ma comporta una consapevolezza e conoscenze più profonde e tempi di apprendimento più lunghi rispetto alla controparte procedurale.
Tuttavia, ciò non significa che non è possibile codice di qualità scrivere senza ignorare del tutto il modello ad oggetti: in questo caso è compito dello sviluppatore sfruttare la totale libertà che gli viene posta dal codice procedurale e produrre script robusti e facilmente mantenibili.
