J'ai lu que la création d'un espace de noms pour les projets JavaScript contribue à réduire les conflits avec d'autres bibliothèques. J'ai du code avec beaucoup de types d'objets différents pour lesquels j'ai défini des fonctions de constructeur. Est-il une bonne pratique de les mettre à l'intérieur de l'espace de noms aussi?
Par exemple: P>
var square = new shapes.Rectangle(10,10);
5 Réponses :
oui. Vous devez polluer l'espace de noms global le moins possible
Cet espacement de noms est appelé " Singleton modèle " et c'est l'un des modèles principaux recommandés par le célèbre " gang de Quatre "Livre des motifs de conception.
du livre génial (et gratuit) Apprentissage des modèles de conception JavaScript : < / p>
classiquement, le modèle singleton peut être mis en œuvre en créant un classe avec une méthode qui crée une nouvelle instance de la classe si une n'existe pas. En cas d'instance déjà existante, il suffit simplement Renvoie une référence à cet objet.Le motif singleton est donc connu Parce qu'il limitent l'instanciation d'une classe à un seul objet.
en JavaScript, Singletons servent de fournisseur d'espace de noms qui isolent code de mise en œuvre de l'espace de noms global afin de fournir un point d'accès unique pour les fonctions.
Ils peuvent prendre un certain nombre de formes différentes, mais dans son plus fondamental, un Singleton pourrait être implémenté comme un objet littéral groupé ensemble Avec ses fonctions et propriétés associées ...
Alors oui, c'est un concept bien utilisé dans de nombreuses langues de programmation et un excellent pour prévenir les collisions d'objet d'espace de noms global en JavaScript.
Voir aussi: moyen le plus simple / propre d'implémenter singleton dans JavaScript?
Super. Merci beaucoup. Aussi merci pour les liens. Je n'ai rien vu d'exemples de quiconque appelant neuf pour une fonction dans un espace de noms et qui se demandait s'il y avait une raison pour cela.
Aucune raison pour laquelle je peux penser. La nouvelle fonction est le héritage prototypique de JavaScript, qui est souvent utilisé dans la pratique en tant que héritage ressemblant à une classe. La plupart des exemples que vous verrez définir une seule "classe", mais si vous essayez d'organiser un groupe d'entre eux, le modèle singleton est également plus utile.
@joe Bien sûr, ce n'est pas considéré comme singleton modèle si le littéral objet contient des constructeurs ;-)
Ouais, c'est une bonne idée, car vous évitez les tracas et déroutants causés par la pollution de l'espace de noms global. Bien que je modifierais personnellement formes à forme , vous pouvez donc avoir une forme .rectangle , ce qui donne un peu plus de sens pour moi (après Tout, un rectangle n'est qu'un seul objet).
En plus de ne pas polluer l'espace de noms, il vous permet également de faire de type Vérification de la famille:
function doSomethingTo(shape) {
var shapeName, validArg;
for (shapeName in shapes) {
validArg = validArg || shape instanceof shapes[shapeName];
}
if ( !validArg ) throw "Argument is not a shape.";
}
C'est généralement une bonne idée; De plus, si vos objets nécessitent un ensemble de fonctions partagées qui ne doivent pas être exposées, vous pouvez les envelopper tous à l'intérieur d'une fermeture, comme un module:
var shapes = (function() {
// private variables
var foo = 0;
// private function
function get_area(w, h)
{
return w * h;
}
return {
Rectangle: function(w, h) {
this.width = w;
this.height = h;
// call private function to determine area (contrived example)
this.area = get_area(w, h);
}
}
}());
var s = new shapes.Rectangle(100, 5);
Votre constructeur, qui est une fonction, devient une expression de fonction au lieu d'une déclaration de fonction si vous l'attribuez à une propriété d'objet dans un "espace de noms" au lieu de simplement écrire
Fonction Rectangle (W, H) {} . Cela a de légères différences: développeur.mozilla.org/de/docs/ Web / JavaScript / référence / ... Autre que cela ne pollue pas l'espace de noms global, qui est une bonne chose, comme d'autres l'ont souligné.