Implémentation de partage de motifs monolithiques en JavaScript

En tant que modèle de développement de logiciels, le modèle monolithique a été largement utilisé dans de nombreuses langues orientées objet. En JavaScript, le motif monolithique est également largement utilisé. Cependant, parce que le langage JavaScript a sa méthode unique orientée objet, il est cohérent avec certaines langues traditionnelles orientées objet, mais elle est toujours différente dans la mise en œuvre.

Tout d'abord, jetons un coup d'œil à la définition des modèles monomères dans les langues traditionnelles orientées objet: les modèles monomères sont des classes qui ne peuvent être instanciées qu'une seule fois et peuvent être accessibles via un point d'accès bien connu. Il y a deux points dans cette définition qui mettent en évidence les caractéristiques des langues traditionnelles orientées objet, à savoir la classe et l'instanciation. Par conséquent, pour les langues traditionnelles orientées objet, le modèle monolithique est basé sur les caractéristiques naturelles de sa classe et de sa instanciation. Autrement dit, utilisez la classe de mots clés pour définir une classe, qui peut être instanciée via le nouveau mot clé, mais il faut s'assurer que chaque fois qu'il est instancié par un nouveau, la même instance est obtenue ou que son constructeur ne peut être appelé qu'une seule fois via Nouveau.

Jetons un coup d'œil à la définition du modèle monomère dans JavaScript: Monomère est un objet utilisé pour diviser l'espace de noms et organiser un lot de méthodes et d'attributs connexes. S'il peut être instancié, il ne peut être instancié qu'une seule fois. En comparant la définition ci-dessus, vous constaterez que la définition du monomère définit ici son essence comme un objet, plutôt que comme une classe dans une langue orientée objet traditionnelle, qui montre également que la langue de JavaScript est basée sur des objets. Dans le même temps, il a été souligné plus tard que si elle peut être instanciée, cela montre qu'il devrait y avoir plusieurs façons de définir des monomères en JavaScript. Il existe une ou plusieurs façons d'instancier qui peuvent être instanciées, c'est-à-dire d'utiliser le nouveau mot-clé pour créer des objets monomères. Cependant, cette méthode n'est pas une caractéristique naturelle de JavaScript elle-même, car les objets créés à l'aide du nouveau mot-clé sont en fait simulés et définis via des fonctions (bien que ES6 ait commencé à prendre en charge le mot-clé de classe, il n'a pas encore été largement pris en charge par le navigateur). Alors, comment utiliser les caractéristiques naturelles de JavaScript pour implémenter les modèles monomères?

 var singleton = {attribut1: true, attribut2: 10, méthode1: function () {}, méthode2: function (arg) {}}

Voici un objet Singleton, qui contient plusieurs propriétés et méthodes. Il est inclus dans la page. Cet objet est créé lorsque JS est chargé. Il s'appelle utiliser singleton.method1 lors de l'appel. Son instanciation est terminée lors de l'exécution de l'analyse JS de chargement de page. Nous n'utilisons pas le nouveau mot-clé pour instancier cet objet. Il s'agit également d'une grande différence entre la mise en œuvre de modèles monolithiques dans les langages JavaScript et traditionnels orientés objet. Cette méthode est plus simple et plus facile à comprendre. Cependant, cette méthode présente plusieurs inconvénients. Un inconvénient évident est qu'il ne fournit pas d'espace de noms. Si d'autres programmeurs définissent également une variable singleton dans la page, il est facile d'écraser et de confondre l'objet monolithique. Donc, pour ce problème, il est réécrit comme suit:

 var myspace = {}; myspace.singleton = {attribut1: true, attribut2: 10, method1: function () {}, method2: function (arg) {}}

Ici, un espace de noms MySpace est défini d'abord, puis le singleton d'objet unique est monté sous cet objet, ce qui réduit considérablement la possibilité de conflits avec d'autres programmeurs et une mauvaise opération. Même si d'autres définissent une variable singleton dans la portée globale, cela ne polluera pas l'objet Singleton. Cela met en œuvre la fonction de division de l'espace de noms et d'organisation de certains attributs et méthodes connexes comme mentionné dans la définition précédente.

Cette méthode a encore ses inconvénients. Toutes les propriétés et méthodes de cet objet monolithique sont partagées et sont accessibles et modifiées à tout moment de l'extérieur. Par conséquent, les fermetures sont utilisées pour simuler des propriétés et des méthodes privées, comme suit:

 myspace.singleton = (function () {var privateAtTribute1 = false; var privateAtTribute1 = [1,2,3]; fonction privateMethod1 () {} function privateMethod2 () {} return {publicAttribute1: true, publicAttribute2: 10, publicMethod1: function () {privataTTrribute1 = tivraTeMeTh1,););) publicMethod2: function (arg) {privateAtTribute1 = [4,5,6]; privateMethod2 ();}}}) ();

Ici, nous attribuons directement une fonction auto-exécutée anonyme à l'objet Monolith. Dans cette fonction, les mots clés VAR et fonction sont utilisés pour définir respectivement ses propriétés et méthodes privées. Ceux-ci ne peuvent pas être directement accessibles en dehors de la fonction (en dehors de l'objet Monolith), car une fois la fonction exécutée, l'espace de sa portée interne sera recyclé, c'est pourquoi les fermetures peuvent être utilisées pour simuler les propriétés et les méthodes privées. Dans cette fonction (fermeture), un objet est finalement renvoyé, qui contient certaines méthodes et propriétés publiques, qui peuvent être appelées directement à l'extérieur. Dans le même temps, car ces méthodes publiques sont définies à l'intérieur de la fonction, elles peuvent appeler leurs propriétés et méthodes privées. Cependant, le monde extérieur ne peut effectuer certaines opérations que par le biais des méthodes et propriétés publiques retournées, et ne peut pas appeler directement des propriétés telles que Singleton.privateMethod1. Cela fait que l'objet monolithique a non seulement isolé le monde extérieur pour accéder directement à ses propriétés et méthodes privées, mais fournit également quelques propriétés et méthodes communes au monde extérieur pour effectuer certaines opérations.

Ce modèle monolithique construit par auto-exécution des fonctions anonymes est largement utilisé dans de nombreuses bibliothèques JS, mais il y a toujours un problème. Si nous n'avons pas besoin d'utiliser l'objet lors du chargement de la page et que la création de l'objet est plus coûteuse (comme beaucoup de calculs ou un accès multiple à l'arborescence DOM et ses propriétés, etc.), il est raisonnable de le créer lorsqu'il est nécessaire, plutôt que de le créer directement avec l'analyse et l'exécution de JS. Ce concept est appelé chargement paresseux, donc modifiez le code ci-dessus comme suit:

 myspace.singleton = (function () {var uniqueInstance; function constructor () {var privateAtTribute1 = false; var privateAtTribute1 = [1,2,3]; function privateMethod1 () {} function privatethod2 () {} return {publicAtTrribute1: True, publicAttribute2: 10, publicMethod1: furet () {) privateattribute1 = true;

Ici, une variable privée unique INSANCE est définie dans la fonction anonyme comme une poignée pour déterminer si un objet monolithique a été créé. Ensuite, tous les attributs et méthodes définis pour l'objet monolithique ont été placés dans une fonction appelée constructeur. Ce n'est que lorsque la fonction est appelée que l'objet monolithique peut être créé, sinon il ne sera pas créé directement. Ensuite, renvoyez un objet, qui contient une méthode GetInstance, qui concerne les appels externes. Lorsque vous appelez la méthode, déterminez d'abord si l'objet monolithique existe. S'il existe, retournez-le directement. Sinon, appelez la fonction du constructeur pour construire l'objet monolithique et le renvoyer. Enfin, si nous appelons une méthode de l'objet monolithique, nous devons utiliser myspace.singleton.getInstance (). PublicMethod1 (). Ici, nous ne créerons cet objet monolithique que lorsque nous appelons de cette façon, sinon l'objet monolithique ne sera pas créé automatiquement, ce qui implémente réellement le chargement à la demande ou le chargement paresseux.