L'idée c'est de vous proposer de rationnaliser le développement objet sous PHP 4 au cas où vous n'auriez pas le choix - sinon passez à PHP 5.
On commence tout d'abord par la définition d'une classe abstraite selon le WIKI :
Classe abstraite
Dans certains langages, une classe peut être partiellement définie. En particulier, certaines méthodes de cette classe n'ont pas de corps ou d'implémentation. Ces méthodes sont dites
abstraites (ou virtuelles en C++).
Les classes possédant au moins une méthode abstraite sont aussi dites
classes abstraites (ou virtuelles) et ne peuvent pas être instanciées directement -sauf en créant une sous-classe non abstraite.
Exemple : On souhaite modéliser les relations objets d'un dessin vectoriel. On peut dire qu'un objet dessin est un ensemble de géométries (la classe abstraite) et chaque géométrie peut être un point, un polygone ou une ligne brisée (ces trois classes héritent de géométrie). La classe abstraite n'est donc pas indispensable en soi, mais elle est indispensable
[1] pour un modèle propre, générique et simplifié.
Le mixin est un cas particulier de classe abstraite. Il permet d'ajouter un service aux sous-classes.
Interface
Une classe ne possédant que des méthodes abstraites est appelée interface ou classe purement virtuelle (en C++) ou protocole (en Objective C).
Du coup, on comprend vite pk en PHP 4 si on veut faire de la POO cela devient indispensable.
La solution - c'est l'héritage et de créer une classe s'appelant abstractClass par exemple :
$GLOBALS['abstractClass'] = array();
class abstractClass {
function abstractClass($methods) {
$class_name = get_class($this);
if (isset($GLOBALS['abstractClass'][$class_name])) return true;
foreach($methods as $name => $args) $this->checkMethod($name);
$GLOBALS['abstractClass'][$class_name] = $methods;
}
function triggerError($description) {
return trigger_error($description, E_USER_ERROR);
}
function checkMethod($name, $args = NULL) {
if (!method_exists($this, $name)) {
return $this->triggerError('You class '.get_class($this).' must implements '.$name.'('.$args.') function !');
} else return true;
}
function abstractMethods() {
$class_name = get_class($this);
if (isset($GLOBALS['abstractClass'][$class_name])) {
return $GLOBALS['abstractClass'][$class_name] = $methods;
} else {
return $this->triggerError('abstractMethods is not a static method or '.$class_name.' is not a compliant class !');
}
}
}
Lors de la création de votre classe abstraite, faites-la hériter de abstractClass de la manière suivante :
class dbConnector extends asbtractClass {
function dbConnector() {
parent::asbtractClass(array(
'connect' => '$user, $pwd, $host',
'close' => '',
'request' => '$sql'
));
}
}
Lors de la construction de la classe appelez le constructeur de la classe parente en lui spécifiant un tableau composé en indice du nom de la fonction et en valeur de la liste de ses arguments (a titre indicatif).
Voici un exemple concret d'utilisation :
class mySqlConnector extends dbConnector {
function connect($user, $pwd, $host) {
// YOUR CODE
}
function request($sql) {
// YOUR CODE
}
// VOLUTARY FORGET CLOSE FUNCTION ...
}
$db = new mySqlConnector();
// OUTPUT ERROR : You class mySqlConnector must implements close() function !
AVANTAGES : Vous pouvez avoir un gestionnaire d'erreurs qui vérifiera la conformité des définitions de votre classe concrète.
Votre classe abstraite ne pourra pas être construite directement.
DESAVANTAGES : La vérification se fait sur la construction de l'objet et non sur la définition de la classe - du coup l'erreur n'est visible que lors de l'instanciation de l'objet.
La vérification dans le constructeur s'effectue à chaque chargement, du coup baisse des perfs surtout si l'objet est chargé une multitude de fois.
CONSEILS : Méthode à utiliser que sur des classes abstraites qui devront être implémentées par des tiers sinon la vérification n'a pas trop d'importance, on part du principe que vous êtes au point sur votre propre architecture et que vous avez du tps pour débuguer en cas de problème.