Introduction aux modèles d'apparence des modèles de conception JavaScript_Compétences Javascript

Description du mode d'apparence

Explication : le mode Apparence est une interface de haut niveau fournie en raison de la composition complexe de sous-systèmes ou de programmes. Il est plus facile d'accéder au programme ou à l'interface système sous-jacente à l'aide du client

Le mode Apparence est un mode que nous rencontrons souvent. Les fonctions que nous impliquons souvent peuvent devoir impliquer plusieurs sous-interfaces ou sous-systèmes, et l'une de nos fonctions peut n'avoir besoin que d'une ou plusieurs sous-interfaces. paquets séquentiels. Si la fonction métier correspond directement à une sous-interface ou un sous-système, le développeur peut être amené à avoir une bonne compréhension des éléments internes ; vous devrez peut-être comprendre comment se déroule le processus métier, quel est son ordre, etc. Cela nécessite que les développeurs comprennent le métier et rend également la programmation client assez compliquée

S'il existe ici une couche ou une classe qui encapsule spécifiquement les méthodes que nous souhaitons utiliser, la fonction client n'a besoin que d'interagir avec cette classe de couche intermédiaire. Les méthodes correspondantes de la classe de couche intermédiaire sont organisées par les développeurs concernés qui comprennent. l'entreprise. Encapsulation, le programme deviendra alors très simple. Le programmeur n'a besoin que de savoir quelle méthode est requise pour cette fonction, et n'a pas besoin de connaître la logique interne.

Cette classe de couche intermédiaire est ce que nous appelons la classe d'apparence. C'est l'idée du mode apparence.

Exemple de scénario :

1>. Prenons l'exemple d'un interrupteur général. Cet interrupteur général peut commander une lumière sur la porte de votre maison, plusieurs lumières dans le hall, et contrôler l'alimentation électrique de votre téléviseur, de votre réfrigérateur, etc. tu mets ? Appuyez sur "ON", et tout aura de l'électricité, ou même émettra directement de la lumière et de la chaleur. Vous n'avez pas besoin de savoir comment sort le bouton de l'interrupteur principal pour produire de l'électricité, ni comment l'appuyer sur le bouton. appareils électriques concernés. Quoi qu'il en soit, appuyez simplement dessus et l'électricité s'allumera.

Ces lumières, téléviseurs, etc. sont les interfaces et petits systèmes que nous souhaitons utiliser ; cet interrupteur principal est notre classe d'apparence, nous pouvons le faire fonctionner directement en lui faisant face.

2>. C'est comme une entreprise avec plusieurs départements fonctionnels. Lorsque le patron a besoin de l'état d'exécution de divers aspects du travail, il se rend dans chaque département et demande aux employés comment se passe cette certaine chose. la bonne personne, vous pouvez donner une réponse directe au patron. Si cette personne n'est pas responsable, elle dira au patron, oh, qui est responsable de cela, et le patron devra aller demander à cette personne à quel point c'est gênant. .

Si chaque service fonctionnel a un responsable, le patron peut simplement s'adresser directement à lui pour comprendre la situation. Le patron n'a pas besoin de se soucier de la façon dont le responsable le sait, il a seulement besoin de connaître ces 1,. 2, ou 3 choses. Suivez simplement la situation et l’évolution de l’affaire.

Exemple de code source

Implémentez maintenant le code source selon le scénario de la deuxième instance :

1. Plusieurs fonctions du département :

Département 1 (Département Commercial) :

Département 2 (Département R&D) :

Ce qui précède sont les questions que les chefs de chaque service doivent répondre au patron ;

Ensuite, créez une classe d'apparence pour organiser les questions que le patron souhaite poser
;

Puis le patron a appelé les deux managers devant lui et a commencé à les interroger :

Autres consignes

L'utilisation du mode apparence peut découpler les interfaces ou les classes afin qu'il n'y ait pas besoin de dépendance entre les classes. Lorsque cela n'est pas nécessaire, A doit contenir B, ou B doit contenir A. Cela viole le principe de modification fermée. L'empaquetage de classes d'apparence de couche intermédiaire peut simplifier les appels d'interface, et les appels utilisant des sous-interfaces ou des objets de sous-système deviennent plus libres et organisés.

Les modèles d'apparence apparaissent souvent dans notre programmation. Les modèles d'apparence sont souvent utilisés dans les définitions de modèles des systèmes architecturaux. Nos systèmes utilisent des services d'interface tiers et ajoutent souvent une couche de façade pour organiser les interfaces métier disponibles ;