Interfaces et Classes Abstraites
Les concepts de classes abstraites et d'interfaces sont souvents assez flous quand on débute dans la programmation objet, et on se fourvoie assez souvent sur leur utilisation et leur but. Voila une petite explication qui j'espère sera 1) juste et 2) assez claire pour tout le monde. Si vous pensez que je me fourvoie sur ces 2 concepts de base de la POO, n'hésitez pas à me le faire savoir !
Commençons par le commencement: l'Interface. Une Interface définit une API (Application Programming Interface), dont le seul et unique but est de décrire les méthodes disponibles pour un objet donné. Une Interface ne contient pas de code fonctionnel, seulement des synopsis de méthodes et d'attributs. Par exemple, l'utilisation du mot clé "instanceof" permet de déterminer si un objet donné implémente ou non une interface donnée, et d'adapter le comportement de l'application selon la réponse. Le "type hinting" permet également ce genre de choses:
<?php
interface Bar_Interface {
public function doSomething();
}
class Bar implements Bar_Interface {
public function doSomething() {
echo "something was done.";
}
}
class Foo {
public function doSomething(Bar_Interface $bar) {
$bar->doSomething();
}
}
?>
Dans cet exemple, quand Foo::doSomething() est executée, on est certain que l'objet $bar dispose de la méthode doSomething car il implémente l'Interface Bar_Interface.
Vient ensuite la classe abstraite. La classe abstraite, "abstract class" en V.O., se comporte comme un squelette d'objet. Elle est utile dans le cas où on utilise une série d'objets d'une même famille qui partagent du code commun, mais qui comportent tous leurs particularités propres. Dans ce cas de figure, on commence par implémenter le code commun dans la classe abstraite, dont hériteront les autres objets, dans lesquels le code spécifique pourra à son tour être implémenté. C'est très utile pour certains Design Pattern, comme par exemple "Adapter" ou "Proxy", qui ont tous deux pour but de permettre des stratégies différentes pour une même situation, situation qui présente le plus souvent des points similaires quelque soit la stratégie adoptée.
En règle générale, une classe abstraite implémente une interface (et un exemple d'Adapter en cadeau bonux):
<?php
interface Bar_Adapter_Interface {
public function doSomething();
}
class Bar {
public function __construct(Bar_Adapter_Interface $adapter) {
$this->_adapter = $adapter;
}
public function doSomething() {
return $this->_adapter->doSomething();
}
static public function factory($adapter) {
$className = "Bar_Adapter_".$adapter;
if (!class_exists($className)) {
throw new Exception('Adapter not available: '.$adapter);
} else {
return new Bar(new $className);
}
}
}
abstract class Bar_Adapter_Abstract implements Bar_Adapter_Interface {
protected function getSomething() {
return "la méthode pour accéder a ce truc est la même pour tout le monde";
}
}
class Bar_Adapter_Explode extends Bar_Adapter_Abstract {
public function doSomething() {
return explode(' ', $this->getSomething());
}
}
class Bar_Adapter_PregSplit extends Bar_Adapter_Abstract {
public function doSomething() {
return preg_split('/ /', $this->getSomething());
}
}
$bar = Bar::factory('Explode');
print_r($bar->doSomething());
?>
Ici, l'objet Bar offre la méthode doSomething, qui présentement retourne une chaine explosée, et on propose deux adapteurs pour se faire, l'un utilisant explode(), l'autre preg_split(). Bien sur, cet exemple est complètement trivial :-)
Comments
Un collègue avait fait un autre très bon billet là-dessus : http://www.clever-age.com/veille/bl... :-)
Nickel !
Mais il est a préciser un truc important :
En théorie, une interface décrit les méthodes à implément DANS L'ARBRE D'HERITAGE.
En pratique en PHP, cela ce limite aux classes enfants directs de de notre amie l'interface.
On à le même lezard pour la classe abstraite.
C'est vraiment LE truc bête en PHP :(