Abstraction et interfaces PHP
Une question s'est levée lors de mon développement sur une implémentation de classes dans Copix. En effet, rares sont les occasions pour moi de devoir définir des classes abstraites complémentées d'interfaces et je me suis retrouvé devant une implémentation intéressante mais interrogative :)
Je vais simplifier mon concept avec des classes simples. Mais avant cela, un petit rappel sur les principes de bases des classes et méthodes abstraites ainsi que les interfaces.
Les interfaces sont de simples définitions de capacités pour une classe qui doivent être implémentées. En l'occurrence, un véhicule sait "démarrer", "avancer", "reculer", et "freiner"... on va définir un ensemble de capacités pour les objet mobiles:
interface Movable {
public function start();
public function stop();
public function forward();
public function backward();
}
Passons à la classe Véhicule, un Véhicule est une définition dont on pourra hériter, c'est quelque chose d'abstrait car un véhicule doit aussi se décliner en véritable objet: voiture, bateau, avion... ils auront tous les même attributs (couleurs, type de carburant, marque...) mais pourront aussi avoir des capacités particulière, par exemple "voler" pour un avion, flotter pour une bateau...
Par contre, tous véhicule sait démarrer, avancer, freiner... chaque véhicule aura sa propre manière d'avancer... nous avons donc plusieurs moyens de définir ces méthodes... nous allons donc donner ces capacités à tout les véhicule qui redéfinirons ces méthodes.
abstract class Vehicule implements Movable {
protected $color;
protected $type;
protected $mark;
/**
* Example for constructor
*/
public function __construct($stdObject){
$this->color = $stdObject->color;
$this->type = $stdObject->type;
$this->mark = $stdObject->mark;
}
}
Prenons l'exemple d'une voiture, elle hérite d'un véhicule:
class Car extends Vehicule {
public function start(){
//how to start...
}
public function stop(){
//how to stop...
}
public function forward(){
//how to forward... press pedal... etc...
}
public function backward(){
//how to backward... change state, press pedal...
}
}
Les classes dérivants de Vehicule doivent, dans tous les cas, redéfinir les méthodes déclarées dans l'interface Movable...
Jusque là tout me paraissait clair et puis je me suis demandé... pourquoi utiliser une interface ?
En l'occurrence, les méthodes définies pour un véhicule sont appliquées via l'interface, mais comme la classe véhicule est abstraite, les méthodes de l'interfaces le deviennent par la même occasion.
Nous pourrions alors définir Vehicule de cette manière:
abstract class Vehicule {
protected $color;
protected $type;
protected $mark;
/**
* Example for constructor
*/
public function __construct($stdObject){
$this->color = $stdObject->color;
$this->type = $stdObject->type;
$this->mark = $stdObject->mark;
}
//methods to redefine on extended classes
abstract public function start();
abstract public function stop();
abstract public function forward();
abstract public function backward();
}
Ce qui revient au même... La seule différence est que nous n'avons plus besoin de l'interface.
Le choix, selon moi, réside dans l'aptitude d'extraire les méthodes dans un autre bloc qui pourra être utiliser pour autre chose. Effectivement l'interface pourrait parfaitement être utile à autre chose qu'un véhicule... un robot pourrait parfaitement utiliser l'interface "Movable" alors qu'il n'est pas un véhicule...
Je ne sais pas si je me trompe, mais j'aimerai bien être éclairé sur ces questions, dans quel cas vaut-il mieux définir une interface ou des méthodes abstraites ?
Selon vous alors ? Merci à ceux qui pourraient m'aider à y voir plus clair.
Trackbacks
Pour ajouter un trackback (retrolien) sur ce ticket, utilisez cette adresse: http://www.metal3d.org/index.php/trackback/default/tb?id=blog%2F120
Salut !
Je pense que tu as trouvé la raison de faire un choix ou l'autre : il s'agit de la réutilisabilité du composant (ici de l'interface). Si tu penses utiliser d'autres classes "movables", alors le mieux sera certanement d'utiliser cette interface.
Personnellement j'ai tendance à découpler au maximum (donc, dans cet exemple, je pense que je créerais l'interface), mais il est vrai que c'est une question délicate, dans le sens où l'utilité finale ton interface sera l'utilisation qui en est faite dans l'ensemble de l'application/du framework
Merci à toi pour ces réponses, je me doutais bien que le système d'interface était juste un déports de capacités.
Je suis assez d'accord sur le fait de découpler au maximum les fonctionnalités tant qu'on ne perd pas en lecture.
Faudrait avoir d'autres avis tout de même :) hein ?