Comment résoudre le problème de l'utilisation des paramètres de type d'objet dans l'interface PHP qui provoquent l'incompatibilité du type?

Interface PHP et compatibilité des types: Évitez le piège des paramètres de type d'objet

Dans le développement de PHP, le décalage entre la définition de l'interface et le type de classe d'implémentation conduit souvent à l'erreur "doit être compatible avec". Cet article analyse ces problèmes qui surviennent dans une classe de définition et de mise en œuvre d'interface PHP et fournit des solutions.

Problème: l'interface est incompatible avec le type de classe d'implémentation

Supposons que nous définissons une interface IAdminController , où le type de paramètre de la méthode save est object :

 interface iadminController
{
    // ... Autres méthodes ...
    Fonction publique Save (objet $ demande): Array;
    // ... Autres méthodes ...
}

Le type de paramètre de save de la classe est AdminRequest :

 L'administrateur de classe met en œuvre iadmincontreller
{
    fonction publique Save (Administraquest $ demande): Array
    {
        // ... Méthode Body ...
    }
}

Bien que AdminRequest soit une sous-classe d' object (toutes les classes sont implicitement héritées de object ), le runtime rapporte toujours une erreur "doit être compatible avec". Même si gettype($adminRequest) renvoie object , il ne peut toujours pas passer le chèque de type.

Analyse des causes et solutions

Utiliser object comme type de paramètre de méthode n'est pas la meilleure pratique. Bien que toutes les classes héritent de object , cette définition est trop large et manque de garanties de sécurité de type. Lors de la vérification du type, l'interprète PHP vérifie strictement si le type spécifique du paramètre correspond exactement à la définition de l'interface. object en tant que type de paramètre ne limite pas le type spécifique, et même si AdminRequest est un objet, il n'est pas conforme au type object spécifié dans la définition de l'interface.

Une meilleure solution consiste à utiliser des types plus spécifiques comme paramètres d'interface. Si AdminRequest , UserRequest et d'autres classes héritent de la classe Request de Laravel, le type de paramètre de la méthode save est défini comme \Illuminate\Http\Request dans l'interface:

 interface iadminController
{
    // ... Autres méthodes ...
    Fonction publique Save (\ Illuminate \ http \ request $ request): array;
    // ... Autres méthodes ...
}

De cette façon, toutes les classes héritées de \Illuminate\Http\Request peuvent être utilisées comme paramètres de la méthode save , résolvant le problème de l'incompatibilité des types. Cela profite de la nature covariante du système de type PHP, permettant aux signatures de paramètres de sous-classe d'être plus lâche que les classes parentales.

Conseils importants:

• Dans les versions avant PHP 7.2, object a plus de restrictions comme type de signature de méthode. Bien que PHP 7.2 et supérieur prenne en charge object comme type de paramètre, il n'est toujours pas recommandé d'utiliser dans les définitions d'interface.
• L'utilisation de types plus spécifiques peut améliorer la lisibilité du code, la maintenabilité et la sécurité des types.
• Si vous devez utiliser object pour la vérification de type, vous pouvez utiliser is_a() pour la vérification explicite de type à l'intérieur de la méthode, mais cela réduira la sécurité du type du code et réduira la lisibilité. Essayez d'éviter cette pratique.

En sélectionnant une interface de définition de type plus spécifique, vous pouvez éviter efficacement les erreurs d'incompatibilité de type et améliorer la qualité du code.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!