PHP Master | Inversion du contrôle - Le principe hollywoodien

Points de base

• Le concept d'inversion de contrôle (CIO) est plus large que l'injection de dépendance (DI), qui n'est qu'un cas d'application spécifique pour le CIO qui tire parti du CIO. DIVE la conception de la classe pour adopter des collaborateurs externes, fournis par l'environnement environnant;
• IOC, également connu sous le nom de principe hollywoodien, peut aider de manière significative à développer des modules de programme évolutifs et hautement découplés. Il permet à l'environnement externe d'implémenter toute logique nécessaire, simplifiant ainsi l'implémentation du module.
• Le mode observateur est un exemple classique du CIO. Il permet à un corps très découplé d'effectuer certaines tâches spécifiques sans affecter l'environnement environnant, tandis qu'un observateur externe met en œuvre la logique requise pour gérer les événements déclenchés par le corps.
• IOC est une méthode de programmation simple et puissante qui crée des systèmes découplés et orthogonaux dont les composants peuvent être facilement isolés des tests. Il ne se limite pas à la gestion des dépendances en classe, mais peut également être utilisé efficacement dans la conception axée sur les événements.

De nombreux programmeurs (moi-même inclus, c'est donc ce que je pense publiquement mea culpa ) que l'inversion du contrôle (IOC) n'est qu'un synonyme d'injection de dépendance (DI). Il y a une raison plutôt intuitive de cette idée: si le but de la DI est de faciliter la conception des classes afin que ses collaborateurs externes soient fournis par l'environnement environnant, plutôt que de les rechercher à leur tour, alors ce processus peut être effectivement considéré comme un formulaire IOC. Cependant, bien que l'équation di = IOC soit généralement valide, le concept de contrôle de l'inversion lui-même est en fait beaucoup plus large. En fait, on peut dire que DI est un cas d'utilisation spécifique qui tire parti du CIO, mais il est loin d'être le seul. Cela nous ramène au point de départ; si DI est juste un modèle qui repose sur les avantages du CIO, alors qu'est-ce que le CIO? Traditionnellement, les composants d'application sont conçus pour fonctionner et contrôler les environnements d'exécution, et cette approche fonctionne bien dans une certaine mesure. Par exemple, un module de journalisation peut être implémenté pour enregistrer les données dans un fichier, et comment et quand les données sont enregistrées sont complètement contrôlées par le module. Un fichier journal (dans cette partie de l'environnement) n'est qu'un élément externe et passif qui n'affecte pas le fonctionnement du module. Mais supposons que nous devons étendre les fonctionnalités du module et l'activer pour enregistrer en outre les données à la base de données, ou même éventuellement par e-mail. La mise à niveau du module pour exposer des fonctionnalités supplémentaires augmentera sa complexité, et elle deviendra de plus en plus gonflée car la logique requise pour gérer ces tâches supplémentaires est emballée derrière la même API. Cette approche fonctionne, mais elle ne peut pas être étendue du tout. Cette situation peut être résolue d'une manière assez simple. Plutôt que d'avoir le module entièrement responsable de la journalisation des données à plusieurs points de terminaison, nous pouvons déplacer la responsabilité directement vers l'environnement externe. La mise en œuvre du module sera maintenue très simple et limitée à agir comme un planificateur d'événements simples. D'un autre côté, l'environnement sera responsable de la mise en œuvre de toute la logique requise pour enregistrer des données à un point final qui est complètement indépendante du module en question. Sans surprise, le processus d'inversion de ces responsabilités entre les composants et les environnements est officiellement appelé inversion de contrôle (ou en termes plus faciles, principes hollywoodiens), et lors du développement de modules de programme évolutifs et hautement découplés, sa mise en œuvre peut être une réelle amélioration.Bien sûr, le CIO est un paradigme indépendant du langage, il peut donc être facilement utilisé dans le monde PHP.

Implémentez l'inversion du contrôle - Observez l'objet du champ

IOC est en effet partout, il est donc facile de trouver sa mise en œuvre de la production. Le premier cas d'utilisation qui me vient à l'esprit est l'injection de dépendance, mais il existe de nombreux autres cas d'utilisation tout aussi représentatifs, en particulier dans le domaine de la conception axée sur les événements. Si vous voulez savoir dans quels univers parallèles IOC fonctionne avec les mécanismes de gestion des événements, considérez un cas classique dans la bibliothèque GOF: Modèle d'observateur. Les observateurs sont utilisés presque partout, même du côté client via JavaScript, et ce sont des exemples proéminents du concept IOC; pour implémenter la logique requise pour gérer les événements déclenchés par le sujet. Comment gérer les événements, voire de nouveaux événements, est entièrement la responsabilité de l'observateur, et non la responsabilité du sujet. Un exemple pourrait être un excellent moyen de rendre ma longue déclaration précédente plus claire. Supposons donc que nous ayons mis en œuvre un modèle de domaine primitif qui définit une relation un-à-plusieurs entre les articles de blog et les commentaires. Dans ce cas, nous serons intentionnellement ambitieux et permettons au modèle d'envoyer des e-mails pour informer l'administrateur système lorsque de nouveaux commentaires seront ajoutés au message. Honnêtement, la mise en œuvre de ces fonctionnalités sans recourir au CIO serait en fait un gâchis car nous demanderons à l'objet de domaine de faire quelque chose au-delà de sa portée. Au lieu de cela, nous pouvons adopter une approche basée sur le CIO et définir la classe de domaine suivante:

(L'exemple de code est omis ici parce que cette partie du contenu n'a rien à voir avec la pseudo-originalité requise par la question et est trop longue.)

Contrôle de confiance à l'environnement externe - Réalisez le service de notification des commentaires

Construire un service d'observateur qui déclenche des notifications par e-mail lors de l'ajout de nouveaux commentaires à un article de blog est un processus simple qui simplifie pour définir une classe qui implémente la méthode pertinente update(). (L'exemple de code est également omis ici, pour la même raison que ci-dessus.)

Résumé

L'inversion de contrôle est souvent considérée comme un concept obscur, en particulier en PHP, où de nombreux développeurs ont tendance à l'associer à une injection de dépendance ordinaire, mais c'est un moyen simple et puissant de programmer, s'il est mis en œuvre correctement, c'est un excellent moyen de créer Un système découplé et orthogonal dont les composants peuvent être facilement isolés des tests. Si vous utilisez l'injection de dépendance dans votre application (vous l'utilisez effectivement, non?), Vous devriez sentir que votre instinct de programme Cependant, comme j'ai essayé de le démontrer auparavant, il existe de nombreuses situations qui correspondent à cette approche en plus de gérer les dépendances en classe de la bonne manière. La conception axée sur les événements est bien sûr un bon exemple.

(La partie FAQ est omise ici, la même raison que ci-dessus.)

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!