In questo capitolo verranno illustrate le principali classi helper utilizzate dall'applicazione e-commerce del nostro progetto e spiegheremo come implementare tali classi e perché implementarle.
Divide et impera
Il rischio di creare classi gigantesche e monolitiche è sempre in agguato. Se si segue questo approccio la gestione del codice risulta problematica e soprattutto si crea qualcosa che non può essere riutilizzato.
Una classe helper, come indica il suo nome, aiuta le classi principali a svolgere il loro lavoro senza costringerci a ripetere ogni volta le stesse routine (DRY: Don’t Repeat Yourself).
Un esempio di classe helper è una classe che gestisce le richieste HTTP o le sessioni.
Gestire le richieste HTTP
La classe Router gestisce i codici di stato, il content type e i redirect HTTP. Si tratta di una classe dalla struttura semplice:
class Router {
public static function status($code = '404', $msg = 'Not Found') {
if(!headers_sent()) {
header('HTTP/1.1 ' . $code . ' ' . $msg);
}
}
public static function mime( $mime ) {
if(!headers_sent()) {
header( 'Content-Type: ' . $mime );
}
}
public static function redirect($url) {
if(!headers_sent()) {
header('Location: ' . $url);
exit;
}
}
}Stiamo usando la funzione headers_sent() perché vogliamo evitare di generare errori qualora gli header HTTP siano già stati impostati. È utile ricordare che non può esservi nessun tipo di output prima dell’impostazione degli header. In caso contrario PHP solleverà un errore.
Lo stesso principio si applica alle sessioni: una sessione PHP crea un cookie di sessione che verrà appunto inviato al browser tramite header HTTP.
Gestire le sessioni
In PHP una sessione viene inizializzata con session_start() e terminata con session_destroy(). Per impostazione predefinita i dati di una sessione (stringhe) vengono salvati in memoria usando l’array associativo globale $_SESSION. Possiamo paragonare questo array ad una tabella in cui a ciascuna chiave viene associato un valore.
Possono essere memorizzati solo dati semplici come stringhe. I dati complessi (array, oggetti) devono essere prima serializzati come stringhe e quindi salvati. Ricordiamo che PHP tiene traccia della sessione verificando sempre che vi sia un’invocazione alla funzione session_start() nelle varie pagine. invocazione che, come per header e cookie, deve precedere qualsiasi tipo di output.
Se tale invocazione non è presente, i dati salvati nell’array globale non saranno accessibili.
La classe Session gestisce le sessioni permettendoci anche di serializzare i dati del carrello e di reperire i dati salvati tramite le funzioni serialize() e unserialize().
class Session {
public static function start() {
session_start();
}
public static function setItem($key, $value, $serialize = false) {
if(!$serialize) {
$_SESSION[$key] = $value;
} else {
$_SESSION[$key] = serialize($value);
}
}
public static function getItem($key, $unserialize = false) {
if(!$unserialize) {
return $_SESSION[$key];
} else {
return unserialize($_SESSION[$key]);
}
}
public static function hasItem($key) {
return (isset($_SESSION[$key]));
}
public static function end() {
session_destroy();
$_SESSION = [];
}
}Il reset conclusivo dell’array globale della sessione viene effettuato per cancellare dalla memoria i dati ancora presenti liberando così risorse utili.
Conclusione
Abbiamo visto come dividendo i compiti con delle classi helper si semplifichi notevolmente il processo di sviluppo. Nei prossimi capitoli entreremo nel merito delle varie pagine che compongono il nostro e-commerce.
