Abstraction et interfaces PHP

23/09/2008

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.

Ça peut vous intéresser aussi


Thread PHP dans Copix

Alors qu’on discutait sur le canal #fedora-fr de langages,...


Optimisations Copix PHP et Apache

Les temps de réponse… Dieu sait à quel point cela ...


Thread PHP dans Copix via HTTP

Dans le précédent post Thread PHP dans Copix, j’ai présenté la ...


Poste de développement PHP sous Fedora

Linux est un système parfait pour développer. Simple d’installation,...

Merci de m'aider à financer mes services

Si vous avez apprécié cet article, je vous serai reconnaissant de m'aider à me payer une petite bière :)

Si vous voulez en savoir plus sur l'utilisation de flattr sur mon blog, lisez cette page: Ayez pitié de moi

Commentaires

Ajouter un commentaire

pseudo.nash - 24/09/2008

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

Metal3d - 24/09/2008

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 ?

Ajouter un commentaire

(*) Votre e-mail ne sera ni revendu, ni rendu public, ni utilisé pour vous proposer des mails commerciaux. Il n'est utilisé que pour vous contacter en cas de souci avec le contenu du commentaire, ou pour vous prévenir d'un nouveau commentaire si vous avez coché la case prévue à cet effet.