[POO][PHP] Utilité des interfaces ?

[Ter Rowan]

yop, suite à divers fils de discussion, j'ai cherché à comprendre le principe d'interface. Après quelques articles je n'arrive pas a trouvé une véritable utilité à ce système.

j'expose ce que j ai compris et ce que j'en déduis dites moi si je me trompe ou pas :


- l'interface en tant que telle ne génère aucun code, on ne peut donc pas l'envisager comme une classe mère qui aurait des méthodes réutilisables par ses classes filles

- j'en déduis qu'il faut que toutes les classes implémentant l'interface doivent physiquement posséder des méthodes correspondant aux "méthodes virtuelles" de l'interface.

- donc, en dehors d'un aspect purement "prototypage" (que j'apprécie en C d'ailleurs) l'implémentation ne fait rien en tant que telle



j'en déduis que ca ne me sert a rien.... du coup j'ai du mal à comprendre pourquoi on a créé cette notion. Y a un truc que je ne vois pas mais quoi ?

[Sephi-Chan]

De ma petite expérience (qui ne s'allongera pas de si tôt puisque Ruby n'inclut pas d'interfaces), ça sert à ajouter des contraintes qui obligent à faire bien les choses.

C'est par exemple utilisé dans certains frameworks qui fournissent des systèmes qui peuvent avoir plusieurs backend pour un système. Imagine par exemple un système de cache pour lequel tu veux des méthodes homogènes : store(), destroy(), get() mais que derrière, tu as plusieurs backend : une classe qui cache à base de fichiers, l'autre qui utilise APC, etc. Il est alors intéressant d'utiliser une interface contenant ces quelques méthodes indispensables, ainsi, tu es certain de la fiabilité de ton système.

Ça pourrait être la même chose avec un système d'internationalisation : tes ressources traduisibles implémentent une interface qui peut utiliser indifféremment getText ou d'autres systèmes.

Je crois me souvenir que Zend Framework utilise ça pour Zend_Cache et probablement pour d'autres composants : je te conseille de jeter un œil au code source, il y a du beau PHP dedans.

• Developpez.com - À quoi servent les interfaces en PHP ?
  

Sephi-Chan

[Anthor]

A priori dans Zend elle servent même de base à toute classe Ou des classes abstraites, tout dépend si il existe des méthodes communes.

C'est à mon sens un des points les plus important de la POO, puisqu'il permet justement d'avoir cette cohérence entre les différentes classes, en te permettant facilement de ne pas sortir des conventions que tu t'es fixé.

[SorenS]

Ca permet de définir un cadre en effet.

Un exemple que j'ai puisé dans l'excellent ouvrage "PHP 5 avancé" :
Tu as une classe voiture, une classe train. Tu leur met l'interface peutRouler.
Tu définis ensuite qu'une voiture ou un train peut entrer en collision avec tout ce qui peutRouler.

De plus, une classe peut implémenter plusieurs interfaces contrairement aux classes abstraites.

[JauneLaCouleur]

Une interface est un élément de la programmation orienté objet, pour faire simple, c'est un classe dont toutes les méthodes sont abstraites. Une classe peut implémenté plusieurs interface, c'est très utile, et très puissant, car le multi-héritage n'existe pas en PHP ou en Java. Et comme la plus part des mécanismes de la POO, ca permet de faire du code maintenable, polyvalent et relativement plus stable. Bien entendu, en PHP, il faut faire de la vérification de type mais c'est une question d'habitude...

Après, tout dépend de l'ampleur que tu donne à ton code, si c'est des scripts à base de copier/coller, et/ou sans réflexion particulière avant de coder, les interface ne servent à rien, tout comme les classes d'ailleurs.

Jet un œil a l'API Java, tu verras qu'il y a des interfaces partout, et cela t'aidera peut être à comprendre l'utilité des interfaces.

[Ter Rowan]

oki c'est bien ce que je pensais, ça va servir mais plus pour sécuriser/qualifier la qualité du code que pour "factoriser" du développement

en tout cas le lien que tu as donné Sephi est vraiment bien foutu

[Argorate]

Les interfaces sont pour moi d'une inutilité qui m'ont d'abord abassourdis et qui m'ont finalement fait rire.

Leurs fonctions : obliger le programmeur a définir des méthodes par exemple.

Sachant cela et sachant qu'il faut une selection + SUPPR pour enlever une interface et donc retirer leur "obligation", c'est a mon sens pas très utile.

De plus je concidere que quand on créé un programme on sait comment il marche de bout en bout et de se qu'on a besoin pour arrivé a le finaliser.
Sachant cela, créer des interfaces pour s'assurer que des choses existeront alors qu'elles doivent exister pour que le programme marche est une forme de redondance a mon sens -donc inutile au possible.

Maintenant je sais que vous êtes pas d'accord, mais j'avais quand meme envis de signalé mon point de vue.
Donc je rejoin l'un des avis donné sur le lien de Séphi:

En soit une Interface ne sert strictement à rien pour l'application mais juste à "aider" le developpeur

[Sephi-Chan]

On ne peut pas dire que ce soit inutile pour autant : dans un développement où tu utilises des librairies tierces, telles qu'un framework, les interfaces t'évitent des problèmes. Après, c'est sûr que dans un jeu par navigateur…
Encore que, on peut tout à fait imaginer un moteur de jeu avec des tests du genre "Si le PNJ implémente l'interface Attaquable, alors…" et là, ça peut être sympa, notamment dans le cas d'un moteur de jeu open source.


Sephi-Chan

[Zamentur]

Encore que, on peut tout à fait imaginer un moteur de jeu avec des tests du genre "Si le PNJ implémente l'interface Attaquable, alors…" et là, ça peut être sympa, notamment dans le cas d'un moteur de jeu open source.


Sephi-Chan

J'y avais pas pensé!
C'est une super remarque...

Sinon çà dépend un peu du nombre de développeur sur le projet... Une interface peux permettre de communiquer sur ce qui est obligatoire de faire pour que çà fonctionne, mieux qu'un phpdoc...

[Morningkill]

Une interface, c'est effectivement un contrat (bien que la "programmation par contrat" ca soit encore autre chose).
Si une classe implémente une interface, elle doit alors implémenter toutes les méthodes de cette interface.

Alors, oui, un contrat c'est contraignant (aspect "force le developpeur"), mais c'est aussi une sécurité, et ca permet une "unicité de traitement" (plus l'aspect multi heritage). On peut me passer un objet de n'importe quel type, du moment qu'il implémente l'interface dont j'ai besoin.

Pour moi, c'est un point essentiel de la POO (avant d'avoir bien compris ce que c'était (avec du coup tout les concepts afférents et usages possibles (style design pattern), je ne pense pas que je faisais de la POO, juste des structures avec des fonctions (enfin, y avait l'heritage, quand même) ).

Aprés, dans un jeu web en php, je sais pas.