Une analyse approfondie des modèles d'apparence dans le framework Laravel

LaravelLe modèle de façade dans le cadre est que la communication externe avec un sous-système doit être effectuée via un objet de façade unifié pour fournir une interface cohérente pour un ensemble d'interfaces dans le sous-système. une interface de haut niveau qui rend ce sous-système plus facile à utiliser. Le mode apparence est également appelé mode façade, qui est un mode de structure d'objet.

Les façades Route, Redis et Auth que nous utilisons couramment dans Laravel sont les implémentations spécifiques du modèle d'apparence Plusieurs classes d'apparence sont conçues dans Laravel, et chaque classe d'apparence hérite de la classe d'apparence unifiée. La classe d'apparence abstraite fournit des méthodes de base pour accéder au sous-système derrière elle via la classe d'apparence.

Pour les nouveaux besoins métier, ne modifiez pas la classe d'apparence d'origine, mais ajoutez une nouvelle classe d'apparence spécifique. La nouvelle classe d'apparence spécifique est associée au nouvel objet du sous-système, et en même temps, elle est obtenue par. modifier le fichier de configuration. Le but n'est pas de modifier le code source et de remplacer la classe d'apparence.

Ce qui suit est un exemple de modèle d'apparence simple, qui n'introduit pas de classe d'apparence abstraite. Dans l'article présentant Laravel Facade, nous verrons que Laravel fournit une classe d'apparence abstraite afin que nous puissions facilement la personnaliser. en fonction de nos besoins. Ajoutez la classe d'apparence du nouveau sous-système et activez la classe d'apparence pour qu'elle soit correctement proxy vers son sous-système (ou service) correspondant.

Structure du mode

Le mode Apparence contient les rôles suivants :

• Rôle d'apparence de façade

• Rôle du sous-système SubSystem

Exemple de code

<?php class Client
{
    public function main()
    {
        (new Facade)->operation();
    }
}

class Facade
{
    private $systemA;
    private $systemB;
    
    public function __construct()
    {
        $this->systemA = new SystemA;
        $this->systemB = new SystemB;
    }
    
    public function operation()
    {
        $this->systemA->operationA();
        $this->systemB->operationB();
    }
}

class SystemA
{
    public function operationA()
    {
        //
    }
}

class SystemB
{
    public function operationB()
    {
        //
    }
}

Analyse de modèles

Selon le « principe de responsabilité unique », la division d'un système en plusieurs sous-systèmes dans un logiciel est utile pour réduire la complexité de l'ensemble du système. Un objectif de conception commun est de permettre la communication et l'interaction entre les sous-systèmes. Les dépendances sont minimisées et une façon d'atteindre cet objectif consiste à introduire un objet de façade, qui fournit un point d'entrée simple et unique pour accéder au sous-système. -Le mode apparence est également l'incarnation de la « loi de Déméter ». En introduisant une nouvelle classe d'apparence, la complexité du système d'origine peut être réduite et le couplage entre la classe client et la classe du sous-système peut être réduit. - Le modèle d'apparence nécessite que la communication entre l'extérieur d'un sous-système et son intérieur s'effectue via un objet d'apparence unifié. La classe d'apparence sépare le client de la complexité interne du sous-système, de sorte que le client n'a qu'à gérer l'apparence. objet sans Travailler avec de nombreux objets au sein du sous-système. -Le but du mode apparence est de réduire la complexité du système. -Le mode d'apparence améliore considérablement la commodité d'utilisation du client, de sorte que le client n'a pas besoin de se soucier des détails de fonctionnement du sous-système et peut appeler les fonctions associées via le rôle d'apparence.

Inconvénients

Inconvénients du mode apparence

• Impossible d'empêcher les clients d'utiliser correctement les classes du sous-système, si vous en faites trop pour que les clients accèdent aux classes du sous-système. Limitations réduire la variabilité et la flexibilité.

• Sans introduire une classe d'apparence abstraite, l'ajout d'un nouveau sous-système peut nécessiter de modifier le code source de la classe d'apparence ou du client, ce qui viole le « principe d'ouverture-fermeture ».

Extensions de modèle

• Un système a plusieurs classes d'apparence

  En mode apparence, une seule classe d'apparence est généralement nécessaire, et cette classe d'apparence n'a qu'une seule instance, autrement dit c'est une classe singleton. Dans de nombreux cas, afin d'économiser les ressources système, les classes d'apparence sont généralement conçues comme des classes singleton. Bien entendu, cela ne signifie pas qu'il ne peut y avoir qu'une seule classe d'apparence dans l'ensemble du système. Plusieurs classes d'apparence peuvent être conçues dans un système. Chaque classe d'apparence est chargée d'interagir avec certains sous-systèmes spécifiques et de fournir les fonctions métier correspondantes aux utilisateurs.

• N'essayez pas d'ajouter de nouveaux comportements au sous-système via des classes d'apparence

  N'ajoutez pas de nouveaux comportements au sous-système en héritant d'une classe d'apparence. Cette approche est erronée. . Le but du modèle d'apparence est de fournir un canal de communication centralisé et simplifié pour les sous-systèmes, plutôt que d'ajouter de nouveaux comportements au sous-système. L'ajout de nouveaux comportements doit être réalisé en modifiant la classe de sous-système d'origine ou en ajoutant une nouvelle classe de sous-système. être implémenté via des classes d’apparence.

• Introduction de classes d'apparence abstraites

  Le plus gros inconvénient du mode apparence est qu'il viole le "principe d'ouverture et de fermeture", qui est requis lors de l'ajout de nouveaux sous-systèmes ou de la suppression sous-systèmes La modification de la classe d'apparence peut résoudre ce problème dans une certaine mesure en introduisant des classes d'apparence abstraites et des programmes clients pour les classes d'apparence abstraites. Pour les nouveaux besoins métier, la classe d'apparence d'origine n'est pas modifiée, mais une nouvelle classe d'apparence spécifique est ajoutée. La nouvelle classe d'apparence spécifique est associée au nouvel objet du sous-système. En même temps, le fichier de configuration est modifié pour atteindre l'objectif. ne pas modifier le code source et le remplacer. Objectif de la classe d'apparence.

Résumé

• En mode apparence, la communication externe avec un sous-système doit être effectuée via un objet d'apparence unifié, qui est un groupe de sous-systèmes L'interface fournit une interface cohérente, et le modèle de façade définit une interface de haut niveau qui rend ce sous-système plus facile à utiliser. Le mode apparence est également appelé mode façade, qui est un mode de structure d'objet.

• Le mode apparition contient deux rôles : le rôle apparition est un rôle qui est directement appelé sur le client. Dans le rôle apparition, vous pouvez connaître les fonctions et responsabilités de la personne concernée. ou plusieurs) sous-systèmes , il délègue toutes les demandes du client au sous-système correspondant et les transmet à l'objet du sous-système correspondant pour traitement. Il peut y avoir un ou plusieurs rôles de sous-système dans le système logiciel en même temps, et chaque sous-système peut ne pas l'être ; une classe A distincte, mais un ensemble de classes qui implémente les fonctions d'un sous-système.

• Le modèle d'apparence nécessite que la communication entre l'extérieur d'un sous-système et son intérieur s'effectue via un objet d'apparence unifié. La classe d'apparence sépare le client de la complexité interne du sous-système, créer le client La fin n'a besoin que de gérer les objets d'apparence et n'a pas besoin de gérer de nombreux objets à l'intérieur du sous-système.

• Le principal avantage du mode apparence est de protéger les composants du sous-système des clients, de réduire le nombre d'objets traités par les clients et de rendre le sous-système plus facile à utiliser. Il réalise la communication entre le sous-système et les clients. Il couple faiblement la relation, réduit les dépendances de compilation dans les grands systèmes logiciels et simplifie le processus de transplantation de systèmes entre différentes plates-formes ; son inconvénient est qu'il ne peut pas vraiment restreindre l'utilisation des classes de sous-systèmes par les clients et qu'il n'introduit pas de classes d'apparence abstraites. Dans certains cas, l'ajout d'un nouveau sous-système peut nécessiter la modification de la classe d'apparence ou du code source du client, violant ainsi le « principe d'ouverture-fermeture ».

• Les situations applicables du modèle d'apparence incluent : fournir une interface simple pour un sous-système complexe ; il existe une grande dépendance entre le programme client et plusieurs sous-systèmes dans une structure hiérarchique ; chaque couche du système doit être définie de manière à ce qu'il n'y ait pas de connexion directe entre les couches.

Ce qui précède représente l'intégralité du contenu de cet article. Pour plus d'informations, veuillez prêter attention au Tutoriel de démarrage de Laravel Framework.

Articles connexes recommandés :

Analyse du code source du middleware basé sur laravel5.2

Construction de l'environnement local Laravel : Homestead Déploiement de l'environnement de développement

Recommandations de cours associées :

Cinq derniers didacticiels vidéo Laravel recommandés en 2017

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!