Vous devez utiliser le mode de conception car il peut résoudre des problèmes pratiques tels que la communication des composants, la réutilisation de la logique, la maintenance du code, etc. Par exemple, en utilisant la logique d'encapsulation en mode module pour éviter la pollution globale du mode observateur pour obtenir des exemples de gestion unifiés en mode de communication axé sur les événements. Les modèles communs incluent le mode module pour fournir des interfaces publiques pour améliorer l'organisation du code par l'encapsulation de fermeture des variables privées; Mode d'observateur pour atteindre la communication entre les composants à couplage librement par des méthodes sur et émettre des méthodes; Mode singleton pour assurer la cohérence globale en exportant des instances uniques. Cependant, lorsque les petits projets ou équipes ne se familiarisent pas, il n'est pas conseillé de surmonter le modèle de conception. Des modèles communs tels que les modules, les usines et les observateurs doivent être prioritaires pour reconstruire le modèle de conception lorsqu'il y a des difficultés de duplication ou de maintenance.

Lorsque vous écrivez du code JavaScript, vous pouvez simplement implémenter les fonctions au début, mais à mesure que le projet augmente et que le travail d'équipe augmente, vous constaterez que le simple fait de fonctionner ne suffit pas. Si vous souhaitez écrire des codes avec une structure claire, une maintenance pratique et une forte évolutivité, le modèle de conception est devenu un lien incontournable.

Pourquoi avez-vous besoin d'utiliser des modèles de conception?

Beaucoup de gens pensent initialement que le modèle de conception est "trop compliqué" ou "inutile", mais en fait, il résout le vrai problème: par exemple, comment communiquer plus clairement entre les composants? Comment éviter la logique en double? Comment rendre le code plus facile à tester et à modifier?

Pour donner l'exemple le plus simple: vous avez une bibliothèque de fonctions d'outils. Si vous appelez ces fonctions directement partout, une fois que vous souhaitez modifier le nom ou modifier la méthode d'implémentation, vous devez le modifier un par un. Si vous utilisez un module de module ou un singleton, vous pouvez gérer ces dépendances de manière centralisée et prendre effet à l'échelle mondiale s'ils les changent.

Plusieurs modèles de conception JavaScript communs et pratiques

1. Modèle de module

Le motif du module est l'un des moyens les plus couramment utilisés pour organiser le code. Il peut vous aider à encapsuler la logique pertinente dans un objet et à éviter de polluer l'espace de noms global.

 const mymodule = (function () {
  const privatevar = 'secret';

  fonction privateMethod () {
    console.log (?Ceci est privé?);
  }

  retour {
    publicMethod: function () {
      Console.log (?Méthode publique Accès?, privatevar);
    },
  };
}) ();

Les avantages de cela sont:

• Les variables ne sont pas exposées
• Fournit une interface propre pour une utilisation externe
• Plus facile d'organiser les structures de code

2. Modèle d'observateur

Le mode observateur convient aux systèmes basés sur des événements, tels que la communication entre les composants de l'interface utilisateur.

Par exemple, lorsque vous créez un composant de formulaire, lorsqu'un certain champ change, d'autres pièces doivent répondre. à l'heure actuelle, ces composants vous abonnent à des événements "changements de champ" au lieu du couplage codé dur.

L'implémentation peut être très simple:

 class EventEMmitter {
  constructeur () {
    this.Handlers = {};
  }

  sur (événement, gestionnaire) {
    if (! this.handlers [événement]) this.Handlers [événement] = [];
    this.Handlers [événement] .push (gestionnaire);
  }

  émettre (événement, données) {
    if (this.handlers [événement]) {
      this.Handlers [événement] .ForEach (handler => handler (data));
    }
  }
}

Ce mécanisme se reflète dans les systèmes d'événements de Vue et React.

3. Modèle singleton

Parfois, vous voulez qu'une classe soit instanciée une seule fois dans toute l'application, comme le centre de configuration, le service de journal, etc.

Dans JavaScript, il convient naturellement aux singletons, car nous pouvons dire directement un objet au lieu d'une classe:

 // logger.js
Exporter par défaut {
  log (message) {
    console.log (`[log]: $ {message}`);
  },
};

De cette fa?on, peu importe où il est introduit, c'est la même instance et ne nécessite pas de nouveaux fois.

Quand ne devriez-vous pas utiliser le modèle de conception?

Ne vous contentez pas de définir le mode dès votre arrivée. Le motif de conception n'est pas une solution miracle, mais parfois elle compliquera les problèmes simples.

Par exemple:

• Le projet est très petit, avec des gadgets ou des scripts de quelques personnes, il n'est donc pas nécessaire de forcer l'abstraction
• Les membres de l'équipe ne connaissent pas certains modèles, ce qui peut conduire à la compréhension des co?ts.
• Certains modes augmenteront la difficulté de débogage, comme le mode proxy, le mode politique, etc.

L'approche recommandée est donc:

• écrivez d'abord le code Runnable
• S'il y a des problèmes tels que la duplication, le couplage grave et la difficulté à maintenir, alors envisagez de refactoriser.
• Lors du choix d'un modèle, vous aurez la priorité pour sélectionner des personnes familières, telles que les modules, les usines et les observateurs.

Fondamentalement, c'est tout. Les modèles de conception ne consistent pas à montrer des compétences, mais à résoudre des problèmes spécifiques. Après avoir ma?trisé plusieurs modèles communs, vous constaterez que votre réflexion est plus claire lors de l'écriture de code et il est plus facile de coopérer avec les autres.

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!