Assolutamente.
Per visualizzare una pagina di solito si eseguono una serie di operazioni che hanno forte natura sequenziale e che spesso mal si prestano ad essere rappresentate tramite classi (a meno di casi particolari). Cio' che invece contribuisce a generare la pagina e' molto spesso rappresentabile come una istanza di una qualche classe.
Ti faccio un esempio classico: un CLIENTE e' un tipico concetto della realta' che si presta ad essere rappresentato tramite un oggetto. Quando sviluppi a oggetti poniti due domande, una volta identificato l'oggetto:
A) Quali sono le caratteristiche di questo oggetto?
B) Quali comportamenti di questo oggetto sono possibili o voglio rappresentare?
Le risposte alla domanda A saranno le proprieta' del tuo oggetto, e quelle alla domanda B ne saranno i metodi.
Esempio: un cliente ha un nome, un cognome, una partita iva, un codice cliente e cosi' via. Queste sono le proprieta' del'oggetto cliente. Allora prendi la classe di entita' che vuoi rappresentare, e crei una bella class con tante proprieta' quante sono quelle che ti interessa modellare:
codice:
public class Cliente {
private $nome;
private $cognome;
private $partitaIva;
private $codiceCliente;
public function getNome() {
return nome;
}
public function setNome($nome) {
$this->nome = $nome;
}
public function getCognome() {
return $this->cognome;
}
public function setCognome($cognome) {
$this->cognome = $cognome;
}
// Qui ci sono gli altri campi che ometto
}
Adesso hai un bella classe chiamata Cliente. Una istanza di questa classe (di oggetti) rappresentera' uno specifico cliente (mentre la classe definisce il comportamento e le proprieta' di quella realta' che hai voluto modellare). Per istanziarlo non fai altro che fare:
codice:
$nuovoCliente = new Cliente();
Nella classe di cui sopra ci sono alcune cose importanti che ti consiglio di fare sempre: in primis, tutte le proprieta' sono dichiarate private. Questo implica che per modificare lo stato interno devi utilizzare uno dei metodi appositi, e non puoi cambiare lo stato a mano da fuori, ma e' l'oggetto che attraverso una interfaccia esterna ti dice quale operazioni e' in grado di effettuare. Questo sistema garantisce cio' che si chiama protezione dei dati o incapsulamento. Che vantaggi ti porta? Semplice: tramite i metodi cosiddetti "getter" e "setter" puoi fare in modo che lo stato dell'oggetto non sia mai uno stato non valido.
Ad esempio, un cliente in base al tuo modello dei dati non puo' non avere un cognome. Supponiamo di avere dichiarato l'oggetto con dei campi pubblici (male!):
codice:
public class Cliente {
public $nome;
public $cognome;
public $codiceCliente;
public $partitaIva;
}
Questo oggetto tu lo puoi istanziare esattamente come prima:
codice:
$nuovoCliente = new Cliente();
e per cambiarne il cognome puoi fare:
codice:
$nuovoCliente->cognome = "Baggio";
Pero' puoi anche fare:
codice:
$nuovoCliente->cognome = "";
e se questo viola una tua condizione sullo stato possibile dell'oggetto, sei nei guai. Ad esempio, l'oggetto cliente deve potere essere salvato su database in qualunque momento, e la colonna corrispondente al campo cognome e' definita come NOT NULL. Se tu fai $cliente->save(); (ipotetica funzione che salva su database), la chiamata fallisce.
Invece, e' corretto proteggere i campi impostandoli come privati e poi imporre i vincoli sul cambiamento di stato sui metodi che definiscono, come gia' detto, il comportamento.
codice:
public class Cliente {
private $cognome;
public function setCognome($cognome) throws IllegalArgumentException {
if ($cognome == "")
throw new IllegalArgumentException("Cognome non valido");
$this->cognome = cognome;
}
}
Questo modo di ragionare ti permette di fare si' che una volta che la classe Cliente e' completa e scritta in modo protetto, errori nel codice esterno alla classe stessa non si possano propagare nella tua classe, che utilizzando incapsulamento / protezione dei dati, una volta priva di bug e' inattaccabile.
Rispondi quotando
