PHP6

 
 
Bonjours.
Je fais de l'objet mais sans aller plus loin parce que pour l'instant j'y ai pas eu trop d'interêt mais ne faisant le tour des possibilités en php5 je suis resté bloqué sur l'utilité concrète d'une "interface".  
d'après le le site php.net voici leur explication :

Avec l'explemple et le bout de code je comprend mais ma question est : A quoi ça sert ? dans quel cas j'en ai besoin.  
Merci !

L'exemple est un peu bidon.
On utilise les interfaces, aussi appelé class abstraite en programmation objet, quand on a plusieurs type d'objets qui ont des méthodes (fonctions) en commun.
Les classes et objets créés sont dit polymorphes.
Celà permet, sans connaître le type exact des objets, de les utiliser de la même manière.
 
Pour donner un exemple (pas forcément utile en PHP), tu peut créer une interface flux. Flux gère un flux de donné, qui peut provenir de diverses sources possibles: fichier, connexion HTTP,  connexion FTP, buffer mémoire. Chaque flux possède une interface commune:
- ouvrir()
- lire()
- écrire()
- fermer()
 
Il est facile avec cette interface de connecter deux flux ensembles, à l'aide de lire() et écrire(). Ainsi une seule fonction peut transférer les données de n'importe quel flux vers n'importe quel autre: sauvegarder une page web dans un fichier, poster un fichier sur un ftp, charger un fichier en mémoire, etc...

Sans vouloir dévier du sujet

Pour moi c'est pas la même chose
 

Ok je comprend le principe et ça commence à bien m'intéresser puisque via ton exemple j'y vois déjà un interêt. En fait, je peux faire un peut pret la même chose pour passer une information issu d'un type de SGBD à un autre type.  
Etant donnée que le bout de code présent au dessus est bidon et n'apporte pas grand chose peux tu me donner un exemple avec un juste un squelette stp ?
merci

( )

Selon mes souvenirs, une interface et une classe abstraite sont 2 choses bien distinctes.
 
 
Edit: grilled

classe abstraite != d'interface
 
une classe abstraite est une classe qui ne sera jamais instanciée, mais qui comprends bel et bien des méthodes (avec un corps), des attributs, etc.
Concrètement, à utiliser quand vous avez besoin de faire un héritage pour plusieurs classes, mais que la classe parente ne vous servira pas (elle est donc juste là pour l'héritage).
 
Une interface, comme disait je sais plus qui sur ce forum, c'est un contrat : en implémentant une interface, vous garantissez que la classe possèdera toutes les méthodes, noms, attributs, listés dans l'interface.
Un exemple peut-être des classes gerant le multilangue : une classe Langue_Fr et une classe Langue_En.  
En implémentant une interface pour ces deux classes, vous garantirez ne pas avoir oublié une méthode, ce qui se soldera par un message d'erreur sur l'une de vos pages en fonction de la langue.
 
Après comme dirait Masklinn, en PHP c'est un peu de la fumisterie les interfaces, puisque ça ne vérifie même pas les types des arguments des méthodes.
Moi j'aime quand même bien, ça évite des bugs si un autre développeur reprend ton taf, et ça évite des erreurs d'inattention

C'est pas hors sujet cela m'intéresse aussi les avis sont la bienvenu :
j'ai trouvé une définition et elle s'approche beaucoup d'une interface :

 
Source

Une interface est une classe abstraite sans membres et dont toutes les méthodes sont abstraites...

 
Ok je pense que ça résume bien la différence entre les deux. Donc l'exemple de nargy sur l'utilité ne peut pas servir à cela.

sauf qu'un classe peut implémenter plusieurs interfaces mais n'hériter que d'une classe abstraite non?

dépend des langages, ça.

ouais, ya chipotage là
Class abstraite pure finale ça vous convient mieux?
 
une exemple, avec SGBD.
Factorisation: pour toutes les BDD tu aura besoin de:
- ouvrir une bdd
- fermer une bdd
- envoyer une requête
- lire le résultat d'une requête
- libérer la mémoire occupé par un résultat
- récupérer un code d'erreur
 
Ce qui donne:
function open($host, $port, $user, $pass, $options);
function close();
function query($q);
function fetch($numrow=-1);
function flush();
function error();
 
Pour mysql:
function open($host, $port, $user, $pass, $options);
$this->db=mysql_connect($host, $port, $user, $pass, $options);
 
function close();
mysql_close($this->db);
 
function query($q);
$this-currentresult=mysql_query($q, $this->db);
 
function fetch($numrow=-1);
return mysql_fetch_array($this-currentresult, $numrow);
 
function flush()
mysql_free_result($this->currentresult);
 
function error();
return mysql_error();
 
NB: ma syntaxe mysql est très vague, à vérifier dans la doc, j'ai simplifié mais il faudrait aussi faire les tests necessaires sur les ressources Mysql.

Donc une interface est là pour garantir l'implémentation des methodes définit dans l'interface.

> Donc une interface est là pour garantir l'implémentation des methodes définit dans l'interface.
- exact
- je te laisse deviner ce qu'il faut ajouter pour faire la même chose avec postgres et odbc. ensuite tu peut utiliser uniformément l'une ou l'autre de ces BDD dans tes scripts PHP.

il est possible de mélanger une interface et un héritage ?

bah oui, tu peux très bien avoir
 
class truc extends chose implements machin{
...
}

dans un language objet pure (PHP faut voire, il me semble que c'es ok) tu peut utiliser autant de combinaisons d'interfaces, de classes hérités que souhaité, et de définitions de membres supplémentaires.

 
C'est d'la bombe ça  

nan, php supporte pas l'héritage multiple.

Il y a que c++ qui le supporte il me semble.

il n'y a pas grand chose qui le supporte, oui...

pas dans tous les langages malheureusement. (ou heureusement)
En java par exemple, tu ne peux pas hériter de deux classes à la fois et pourtant, c'est un langage purement objet. (tout le code dois être dans des classes ou des interfaces)
Le C++, par contre, est un langage objet (mais pas totalement objet) permettant d'utiliser des fonctions n'appartement à aucune classe (petit héritage du C) permet de faire de l'héritage multiple.
 
Comme quoi même en question d'interface et d'héritage, il n'y a pas de régle absolut disant ce qu'il est possible ou pas de faire dans un langage simplement objet ou totalement objet.

Un classe qui implémente une interface doit avoir à l'identique les methodes ou elle peut en avoir en avoir plus dans la meme classe  
ex :
 

Tout à fait.  
La distinction provient uniquement de certains langages qui ne permettent pas l'héritage multiple

tout à fait, mais il y a bien une différence entre "extends" et "implements". Et c'est plutôt à ce niveau là que se situe la différence entre interface et classe abstraite au final, mais tu as tout à fait raison.

Pas vraiment non. Une classe abstraite peut très bien décider de mettre une méthode final pour garantir qu'une sous-classe n'ira pas corrompre sont fonctionnement. Cela peut s'avérer très util lorsque tu dois définir un parttern de factory. Et ceci, c'est tout à fait indépendant de l'héritage multiple ou non. Si l'on considére que l'intreface s'apparente à un contrat, la classe abstraite s'apparenterait plus à un texte lacunaire, une partie de l'info existe déjà, à toi de combler les blancs.

Il te semble vachement mal.
 
Maintenant si on se restreint à C++, Java et PHP () alors oui

Le monsieur te dit que les interfaces correspondent à un cas particulier des classes abstraites: les classes abstraites dont toutes les méthodes sont abstraites
 
Et il a parfaitement raison
 
D'ailleurs en C++ on implémente les interfaces... via des classes abstraites

Dans ce cas tu vas m'expliquer comment faire un constructeur dans une interface

T'es au courant qu'on est pas obligé de définir un constructeur?
 
Et qu'une classe abstraite ne peut pas plus être construite qu'une interface?
 
Je vais te donner un conseil: lis le GoF, tu découvriras probablement plein de trucs

oui, et si je VEUX le définir, fais comment avec une interface?

Arrêter d'être stupide me semblerait être une bonne idée pour commencer, si tu réfléchissais 3 secondes tu te rendrais probablement compte que ta question a autant de sens que "comment je fais pour nager un 100m crawl dans un volcan en éruption"

berceker >> un exemple concret d'utilisation des interfaces en Java. récemment, j'ai eu à coder un programme qui opérait des traitements sur une base Oracle ou une base Access. les traitements étaient identiques.
 
voici le code :

private BddUpdater bdUpdater; // BddUpdater est une interface
(...)
// puis l'utilisateur choisit la base à updater. une fois qu'il a choisi, je créé mon BddUpdater :
if (option.equals("Access" )) {
    bdUpdater = new AccessUpdater(this);
} else if (option.equals("Oracle" )) {
    bdUpdater = new OracleUpdater(this);
}

tu saisis ? les classes AccessUpdater et OracleUpdater implémentent toutes les deux l'interface BddUpdater, et donc implémentent ses méthodes. tout ce que j'ai à faire, c'est d'appeler les méthodes d'update à partir de mon BddUpdater, le polymorphisme me garantit ensuite que la méthode correspondant à la base utilisée sera appelée.
 
pour bien faire, il faudrait faire générer l'updater par un factory, ça permettrait de supporter d'autres SGBD sans toucher au code métier, mais bon, vu que je me cassais de la boite, j'avais pas trop envie de me casser le cul

elle peut en avoir plus, tant qu'elle implémente les méthodes de l'interface. une classe ne peut pas avoir moins de méthodes que l'interface qu'elle implémente, mais le contraire est tout à fait possible

 
Et une interface c'est une classe abstraite spéciale où il n'y a que des blancs à combler, tu confirmes donc ce que je dis
L'interface, c'est juste un truc inventé (par java ?) pour pallier au manque d'héritage multiple de certains langages objet.  
 
D'ailleurs en java, y a des classes "XXXImpl" qui implementent les interfaces "IXXX" pour combler ce manque mais qui oblige à agreger l'implementation en plus d'heriter de l'interface au lieu de simplement hériter d'une classe abstraite qui serait partiellement définie : double lourdeur donc  
 

 
tu veux definir un constructeur d'une classe qui n'est pas instanciable ? LOL  

l'héritage multiple, c'est juste un truc inventé pour pallier au manque d'interfaces de certains langages objet

 
LOL, tu ferais mieux de te renseigner sur l'histoire de l'informatique  
La programmation objet existait avant java, tu sais ça ?
 
(A reflexion con, reflexion con et demi   )

oui, et sais tu que l'humour au second degré existait déjà chez les sumériens ?

Ouais mais l'humour c'est mieux quand c'est drôle, là il n'y a aucune relation entre ta déclaration et la réalité historique donc bon s'pas très très drôle

c'était juste pour souligner le coté absurde de la réflexion de Smaragdus qui disait que les interfaces n'étaient là que pour pallier au manque d'héritage multiple. si vraiment c'était le cas, pourquoi un langage comme C#, sorti bien après Java, ne supporte pas l'héritage multiple ?
l'héritage multiple, pour aussi pratique qu'il soit, amène aussi son lot de soucis, et c'est pour ça que Java ou C# ont fait le compromis de supporter les interfaces à la place. dire que les interfaces sont là pour pallier au manque d'héritage multiple est une connerie sans nom