Explication détaillée du principe d'inversion de dépendance (DIP), les cinq grands principes des compétences PHP

Cet article présente principalement le principe d'inversion de dépendance (DIP), les cinq principes majeurs du PHP orienté objet. Il décrit brièvement le concept et le principe du principe d'inversion de dépendance et analyse les définitions et méthodes d'utilisation pertinentes du PHP Dependency Inversion. Le principe sous forme d'exemples. Ce qui est nécessaire Les amis peuvent se référer à

Cet article explique le principe d'inversion de dépendance (DIP), les cinq grands principes du PHP orienté objet, avec des exemples. Partagez-le avec tout le monde pour votre référence, les détails sont les suivants :

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 degré d’avancement du modèle de conception, 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.

Ici, nous prenons comme exemple la classe des employés

<?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();

Copier après la connexion

Dans workA, la méthode de travail dépend de la mise en œuvre par l'enseignant dans workB ; , transfert de travail Et s'appuyer sur l'abstraction, afin que les objets requis puissent être transmis via des paramètres. 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 d'enseignant est transmise via la méthode set, réalisant ainsi le modèle d'usine. Étant donné qu'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 (par exemple si le fichier de classe dépendant existe ) ) et de 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 l'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 supprime le contrôle du code vers la fenêtre IOC. Ceci est réalisé grâce aux 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 indiqué dans 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>

Copier après la connexion

Cependant, il y a toujours des problèmes avec un tel paramètre, et le fichier de configuration deviendra de plus en plus grande, la relation deviendra de plus en 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 à l'imitation de Spring, c'est-à-dire que les dépendances sont écrites dans le fichier de configuration et les objets requis sont généré 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 un travail 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 le DIP est respecté :

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.

Recommandations associées :

Explication détaillée du principe de substitution de Liskov (LSP) des cinq principes orientés objet de PHP

One des cinq principes orientés objet de PHP Explication détaillée du principe d'isolation d'interface (ISP)

Explication détaillée du principe ouvert-fermé (OCP) des cinq principes orientés objet de PHP

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!