Explication détaillée du cas d'inversion de dépendance PHP

Cette fois, je vais vous apporter une explication détaillée du cas d'inversion de dépendance PHP. Quelles sont les précautions pour l'inversion de dépendance PHP Voici un cas pratique, jetons un coup d'oeil.

Qu'est-ce que l'inversion de dépendance ? Pour faire simple, inverse la relation de dépendance en une interface de dépendance Les concepts spécifiques sont les suivants :

1. Le module supérieur ne doit pas dépendre du module inférieur. tous dépendent d'une abstraction (les classes parentes ne peuvent pas dépendre de sous-classes, elles dépendent toutes de classes abstraites)

2. L'abstraction ne peut pas dépendre du concret, le béton devrait dépendre de l'abstraction.

A noter que l'interface ici n'est pas une interface au sens étroit.

Pourquoi s'appuyer sur des interfaces ? Parce que l’interface incarne l’abstraction du problème, et parce que l’abstraction est généralement relativement stable ou change relativement rarement, le béton est changeant. Par conséquent, l'abstraction des dépendances est la base de l'implémentation de l'extension de code et de la liaison d'exécution (polymorphisme) : tant qu'une sous-classe de la classe abstraite est implémentée, elle peut être utilisée par tous les utilisateurs de la classe. Ici, la notion d’évolutivité est soulignée. Habituellement, l'extensibilité fait référence à l'expansion de comportements connus. Lorsqu'on parle d'interfaces, il est également mentionné que les interfaces doivent être relatives. Cela nous indique que quel que soit le niveau d'avancement du modèle de conception est utilisé, il est impossible d'obtenir une situation en constante évolution sans modifier le code. Parmi les cinq principes de l'orientation objet, je pense que l'inversion des dépendances est le plus difficile à comprendre et à mettre en œuvre.

Nous prenons ici la classe d'employés comme exemple

<?php
interface employee
{
  public function working();
}
class teacher implements employee
{
  public function working()
  {
    echo &#39;teaching...&#39;;
  }
}
class coder implements employee
{
  public function working()
  {
    echo &#39;coding...&#39;;
  }
}
class workA
{
  public function work()
  {
    $teacher = new teacher();
    $teacher->working();
  }
}
class workB
{
  private $e;
  public function set(employee $e)
  {
    $this->e = $e;
  }
  public function work()
  {
    $this->e->working();
  }
}
$worka = new workA;
$worka->work();
$workb = new workB;
$workb->set(new teacher());
$workb->work();

Dans workA, la méthode de travail repose sur la mise en œuvre par l'enseignant ; dans workB, le travail repose plutôt sur l'abstraction, afin que les objets requis puissent être transmis via les paramètres entrants. Le code ci-dessus atteint un certain degré de découplage via l'interface, mais il reste limité. Non seulement l'utilisation d'interfaces, mais aussi l'utilisation d'usines peuvent également atteindre un certain degré de découplage et d'inversion des dépendances.

Dans workB, l'instance de l'enseignant est transmise via la méthode set, réalisant ainsi le mode usine. Puisqu'une telle implémentation est encore codée en dur, afin d'étendre davantage le code, écrivez cette dépendance dans le fichier de configuration , indiquant que workB a besoin d'un objet enseignant, spécifiquement configuré par un programme (comme indiqué ) L'existence ou non du fichier de classe dépendant) et l'implémentation dont il dépend dans la configuration de chargement. Ce programme de détection est appelé conteneur IOC.

J'ai vu le concept d'IOC (Inversion of Control) dans de nombreux articles. En fait, IOC est synonyme de Dependence Inversion Principe (DIP). Lorsque vous mentionnez IOC, vous pouvez également voir quelqu'un mentionner des concepts tels que DI. DI, c'est-à-dire Injection de dépendances, on pense généralement que l'injection de dépendances (DI) et la recherche de dépendances (DS) sont deux implémentations d'IOC. Cependant, avec l'évolution de certains concepts généraux, la relation entre ces concepts est devenue floue et certains pensent que l'IOC est DI. Certaines personnes pensent que la description de l'injection de dépendances est plus appropriée que celle de l'IOC, et la relation entre ces concepts ne sera pas abordée ici.

Dans la conception J2EE classique, la couche DAO et la couche Servicen sont généralement subdivisées en couche d'interface et couche d'implémentation, puis les dépendances sont configurées dans le fichier de configuration. Il s'agit de l'application DIP la plus courante. Le framework Spring est un bon conteneur IOC, qui sépare le contrôle du code de la fenêtre IOC via des fichiers de configuration XML. Spring établit des dépendances entre les objets en fonction des paramètres du fichier de configuration lors de l'exécution.

Comme le montre le code ci-dessous

<bean scopre="prototype" class="cn.notebook.action.NotebookListOtherAction" id="notebookListOtherAction">
  <property ref="userReplyService" name="userReplyService" />
  <property ref="userService" name="userService" />
  <property ref="permissionService" name="permissionService" />
  <property ref="friendService" name="friendService" />
</bean>

Cependant, il y a encore des problèmes avec un tel paramètre, le fichier de configuration deviendra de plus en plus volumineux et la relation entre eux deviendra de plus en plus grande. plus complexe. Nous ne pouvons pas non plus échapper au cauchemar de la modification constante du code à mesure que l'application et l'entreprise évoluent (ici, le fichier de configuration est considéré comme faisant partie du code. Et dans le développement réel, il est rare de simplement modifier le fichier de configuration. Généralement, si le le fichier de configuration est modifié, le code Des modifications correspondantes seront également apportées)

En PHP, il existe également une implémentation similaire à Spring, c'est-à-dire que les dépendances sont écrites dans le fichier de configuration et que les objets requis sont générés via le fichier de configuration. Je pense qu'un tel code est toujours implémenté dans un souci d'implémentation. Dans Srping, le fichier de configuration configure non seulement les dépendances d'exécution d'une classe, mais également la gestion des transactions, l'AOP, le chargement différé, etc. Pour réaliser les fonctionnalités ci-dessus en PHP, la consommation est énorme. Du point de vue du langage, les langages de script dynamiques comme PHP diffèrent des langages compilés dans la mise en œuvre de certaines fonctionnalités polymorphes. Deuxièmement, PHP, en tant que langage de développement agile, met l'accent sur un développement rapide, une logique claire et un code plus simple et plus facile à comprendre. Si divers cadres de modèles de conception sont ajoutés, cela n'est pas conseillé du point de vue de la mise en œuvre technique et de l'efficacité opérationnelle. Le principe fondamental de l’inversion des dépendances est le découplage. S’écarter de ce principe des plus primitifs, c’est mettre la charrue avant les bœufs.

En fait, le principe de l'inversion des dépendances est déjà implicite dans de nombreux modèles de conception. Nous effectuons également des travaux d'inversion des dépendances, intentionnellement ou non. C'est juste qu'en tant que PHP, il n'existe actuellement pas de conteneur IOC relativement complet, peut-être que PHP n'en a pas du tout besoin.

Si DIP est satisfait :

1. Chaque classe de niveau supérieur propose une déclaration d'interface pour les services dont elle a besoin, et les classes de niveau inférieur implémentent cette interface.

2. Chaque classe de haut niveau utilise des services via cette interface abstraite.

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !

Lecture recommandée :

Explication détaillée des étapes pour implémenter le téléchargement multi-images avec Bootstrap+PHP

Explication détaillée de étapes pour implémenter la fonction de panier d'achat avec le framework CI

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!