⊗ppOpIfInr 65 of 107 menu

Interfaces en POO en PHP

Comme vous le savez déjà, les classes abstraites représentent un ensemble de méthodes pour leurs descendants. Une partie de ces méthodes peut être implémentée dans la classe elle-même, et une partie des méthodes peut être déclarée abstraite et nécessiter une implémentation dans les classes enfants.

Imaginons une situation où votre classe abstraite représente seulement un ensemble de méthodes abstraites publiques, sans ajouter de méthodes avec une implémentation.

En fait, votre classe parente décrit l'interface des descendants, c'est-à-dire l'ensemble de leurs méthodes publiques, obligatoires pour l'implémentation.

Pourquoi avons-nous besoin de cela : pour commettre moins d'erreurs lors de la programmation - en décrivant toutes les méthodes nécessaires dans la classe parente, nous pouvons être sûrs que tous les descendants les implémentent vraiment.

Quand cela aide : disons que nous créons notre classe parente et plusieurs descendants. Si ensuite après un certain temps, par exemple, un mois plus tard, nous décidons de créer un autre descendant, nous aurons certainement oublié les détails de notre code et nous pourrions facilement oublier d'implémenter une méthode dans le nouveau descendant. Cependant, PHP lui-même ne permettra pas de perdre la méthode - et affichera simplement une erreur.

Il en va de même pour un autre programmeur, travaillant sur votre projet. Disons que le code de la classe parente a été écrit par vous, puis votre collègue a décidé de créer un autre descendant. Votre collègue ne pourra pas non plus oublier quelques méthodes.

Il y a, cependant, un problème : en fait, nous avons créé notre classe parente pour y écrire des méthodes abstraites publiques, mais nous-mêmes ou notre collègue avons la possibilité d'ajouter accidentellement dans cette classe une méthode non publique ou non abstraite.

Disons que nous voulons physiquement interdire de faire dans le parent d'autres méthodes que les méthodes abstraites publiques. En PHP, pour cela, au lieu des classes abstraites, on peut utiliser des interfaces.

Les interfaces représentent des classes dont toutes les méthodes sont publiques et n'ont pas d'implémentation. Le code des méthodes doit être implémenté par les classes qui implémentent les interfaces.

Les interfaces sont déclarées de la même manière que les classes ordinaires, mais en utilisant le mot-clé interface au lieu du mot class.

Pour l'héritage des interfaces, une terminologie un peu différente est utilisée : on dit que les classes n'héritent pas des interfaces, mais les implémentent. En conséquence, au lieu du mot extends, il faut utiliser le mot-clé implements.

On ne peut pas créer un objet d'une interface. Toutes les méthodes de l'interface doivent être déclarées comme public et ne doivent pas avoir d'implémentation. Une interface ne peut avoir que des méthodes, pas des propriétés. On ne peut pas non plus créer une interface et une classe avec le même nom.

Français
AfrikaansAzərbaycanБългарскиবাংলাБеларускаяČeštinaDanskDeutschΕλληνικάEnglishEspañolEestiSuomiहिन्दीMagyarՀայերենIndonesiaItaliano日本語ქართულიҚазақ한국어КыргызчаLietuviųLatviešuМакедонскиMelayuမြန်မာNederlandsNorskPolskiPortuguêsRomânăРусскийසිංහලSlovenčinaSlovenščinaShqipСрпскиSrpskiSvenskaKiswahiliТоҷикӣไทยTürkmenTürkçeЎзбекOʻzbekTiếng Việt
Nous utilisons des cookies pour le fonctionnement du site, l'analyse et la personnalisation. Le traitement des données est effectué conformément à la Politique de confidentialité.
accepter tout personnaliser refuser