Héritage
L'héritage est un des grands principes de la programmation orientée objet (POO), et
PHP l'implémente dans son modèle objet. Ce principe va affecter la manière dont
de nombreuses classes sont en relation les unes avec les autres.
Par exemple, lorsqu'une classe est étendue, la classe enfant hérite de toutes
les méthodes publiques et protégées, propriétés et constantes de la classe parente.
Tant qu'une classe n'écrase
pas ces méthodes, elles conservent leur fonctionnalité d'origine.
L'héritage est très utile pour définir et abstraire certaines fonctionnalités
communes à plusieurs classes, tout en permettant la mise en place de
fonctionnalités supplémentaires dans les classes enfants, sans avoir à réimplémenter
en leur sein toutes les fonctionnalités communes.
Les méthodes privées d'une classe parente ne sont pas accessible à la classe enfant.
Par conséquent, les classes enfant peuvent réimplémenter une méthode privée eux-mêmes
sans se soucier des règles d'héritage normales.
Antérieur à PHP 8.0.0, cependant, les restrictions final
et static
étaient appliquées aux méthodes privées.
À partir de PHP 8.0.0, l'unique restriction de méthode privée qui est imposé
est private final
sur les constructeurs, car c'est une
manière courante pour "désactiver" le constructeur lors de l'utilisation
de méthodes factory statique à la place.
La visibilité
des méthodes, propriétés et constantes peut être relaxé, c.-à-d. une
méthode protected
peut être marqué comme
public
, mais elles ne peuvent pas être restraint, e.g.
marquer une propriété public
comme private
.
Une exception sont les constructeurs, pour lesquels la visibilité peut être restraintes,
par exemple un constructeur public
peut être annoté
en tant que private
dans la classe enfant.
Note:
A moins que l'autochargement ne soit utilisé, les classes doivent être connues avant d'être
utilisées. Les classes mères doivent être définies avant l'écriture d'un héritage. Cette
règle générale s'applique aussi dans le cas d'héritage ou d'implémentation d'interfaces.
Note:
Il n'est pas autorisé de redéfinir une propriété en lecture-écriture avec une
propriété en lecture seule ou vice versa.
<?php
class A {
public int $prop;
}
class B extends A {
// Illegal: read-write -> readonly
public readonly int $prop;
}
?>
Exemple #1 Exemple d'héritage
<?php
class Foo
{
public function printItem($string)
{
echo 'Foo: ' . $string . PHP_EOL;
}
public function printPHP()
{
echo 'PHP est super' . PHP_EOL;
}
}
class Bar extends Foo
{
public function printItem($string)
{
echo 'Bar: ' . $string . PHP_EOL;
}
}
$foo = new Foo();
$bar = new Bar();
$foo->printItem('baz'); // Affiche : 'Foo: baz'
$foo->printPHP(); // Affiche : 'PHP est super'
$bar->printItem('baz'); // Affiche : 'Bar: baz'
$bar->printPHP(); // Affiche : 'PHP est super'
?>
Compatibilité des types de retour avec les classes internes
Antérieur à PHP 8.1, la plupart des classes ou méthodes internes ne déclaraient pas leur
type de retour, et tout type de retour était autorisé lors de leur héritage.
À partir de PHP 8.1.0, la plupart des méthodes internes ont commencé à déclarer "provisoirement"
leur type de retour, dans ce cas, le type de retour des méthodes doit être compatible avec la classe
parent; Dans le cas contraire, une notification de dépréciation est émise.
Notez que l'absence d'une déclaration de retour explicite est également considérée comme une
erreur de signature, et entraîne donc l'avis de dépréciation.
Si le type de retour ne peut être déclaré pour une méthode de surcharge en raison de problèmes de
compatibilité entre versions de PHP, un attribut ReturnTypeWillChange peut être
ajouté pour passer sous silence l'avis de dépréciation.
Exemple #2 La méthode surchargée ne déclare pas de type de retour.
<?php
class MyDateTime extends DateTime
{
public function modify(string $modifier) { return false; }
}
// "Deprecated: Return type of MyDateTime::modify(string $modifier) should either be compatible with DateTime::modify(string $modifier): DateTime|false, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice" À partir de PHP 8.1.0
Exemple #3 La méthode surchargée déclare un mauvais type de retour.
<?php
class MyDateTime extends DateTime
{
public function modify(string $modifier): ?DateTime { return null; }
}
// "Deprecated: Return type of MyDateTime::modify(string $modifier): ?DateTime should either be compatible with DateTime::modify(string $modifier): DateTime|false, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice" À partir de PHP 8.1.0
Exemple #4 La méthode surchargée déclare un mauvais type de retour sans notice de dépréciation.
<?php
class MyDateTime extends DateTime
{
/**
* @return DateTime|false
*/
#[\ReturnTypeWillChange]
public function modify(string $modifier) { return false; }
}
// Aucune notice n'est déclenchée