Comment créer un espace de noms en JavaScript afin que mes objets et fonctions ne soient pas écrasés par d'autres objets et fonctions du même nom? J'ai utilisé ce qui suit:
if (Foo == null || typeof(Foo) != "object") { var Foo = new Object();}
Y a-t-il une manière plus élégante ou succincte de faire cela?
J'aime ça:
var yourNamespace = {
foo: function() {
},
bar: function() {
}
};
...
yourNamespace.foo();
J'utilise l'approche trouvée sur le site Enterprise jQuery :
Voici leur exemple montrant comment déclarer des propriétés et des fonctions privées et publiques. Tout est fait comme une fonction anonyme auto-exécutable.
(function( skillet, $, undefined ) {
//Private Property
var isHot = true;
//Public Property
skillet.ingredient = "Bacon Strips";
//Public Method
skillet.fry = function() {
var oliveOil;
addItem( "\t\n Butter \n\t" );
addItem( oliveOil );
console.log( "Frying " + skillet.ingredient );
};
//Private Method
function addItem( item ) {
if ( item !== undefined ) {
console.log( "Adding " + $.trim(item) );
}
}
}( window.skillet = window.skillet || {}, jQuery ));
Donc, si vous voulez accéder à l'un des membres du public, il vous suffit d'aller skillet.fry()
ou skillet.ingredients
.
Ce qui est vraiment cool, c'est que vous pouvez maintenant étendre l'espace de noms en utilisant exactement la même syntaxe.
//Adding new Functionality to the skillet
(function( skillet, $, undefined ) {
//Private Property
var amountOfGrease = "1 Cup";
//Public Method
skillet.toString = function() {
console.log( skillet.quantity + " " +
skillet.ingredient + " & " +
amountOfGrease + " of Grease" );
console.log( isHot ? "Hot" : "Cold" );
};
}( window.skillet = window.skillet || {}, jQuery ));
undefined
Le troisième argument,
undefined
est la source de la variable de valeurundefined
. Je ne sais pas s'il est toujours d'actualité, mais si vous utilisez d'anciens navigateurs/standards JavaScript (ecmascript 5, javascript <1.8.5 ~ firefox 4), la variable de portée globaleundefined
est accessible en écriture. réécrire sa valeur. Le troisième argument (lorsqu'il n'est pas passé une valeur) crée une variable nomméeundefined
qui est étendue à l'espace de noms/fonction. Comme aucune valeur n'a été transmise lors de la création de l'espace de noms, la valeur par défaut estundefined
.
Une autre façon de le faire, que je considère comme un peu moins restrictive que la forme littérale d'objet, est la suivante:
var ns = new function() {
var internalFunction = function() {
};
this.publicFunction = function() {
};
};
Ce qui précède ressemble beaucoup à le modèle de module et que cela vous plaise ou non , il vous permet d'exposer toutes vos fonctions en public, tout en évitant la structure rigide d'un objet littéral.
Y a-t-il une manière plus élégante ou succincte de faire cela?
Oui. Par exemple:
var your_namespace = your_namespace || {};
alors vous pouvez avoir
var your_namespace = your_namespace || {};
your_namespace.Foo = {toAlert:'test'};
your_namespace.Bar = function(arg)
{
alert(arg);
};
with(your_namespace)
{
Bar(Foo.toAlert);
}
Je le construit normalement dans une fermeture:
var MYNS = MYNS || {};
MYNS.subns = (function() {
function privateMethod() {
// Do private stuff, or build internal.
return "Message";
}
return {
someProperty: 'prop value',
publicMethod: function() {
return privateMethod() + " stuff";
}
};
})();
Mon style au fil des ans a connu un changement subtil depuis que j'ai écrit ceci et je me retrouve maintenant à écrire la fermeture comme ceci:
var MYNS = MYNS || {};
MYNS.subns = (function() {
var internalState = "Message";
var privateMethod = function() {
// Do private stuff, or build internal.
return internalState;
};
var publicMethod = function() {
return privateMethod() + " stuff";
};
return {
someProperty: 'prop value',
publicMethod: publicMethod
};
})();
De cette manière, je trouve l’API publique et l’implémentation plus faciles à comprendre. Pensez à la déclaration de retour comme étant une interface publique pour la mise en œuvre.
Étant donné que vous pouvez écrire différents fichiers JavaScript et les combiner ultérieurement ou non dans une application, chacun doit pouvoir récupérer ou construire l'objet d'espace de nom sans endommager le travail des autres fichiers ...
Un fichier peut avoir l'intention d'utiliser l'espace de noms namespace.namespace1
:
namespace = window.namespace || {};
namespace.namespace1 = namespace.namespace1 || {};
namespace.namespace1.doSomeThing = function(){}
Un autre fichier peut vouloir utiliser l'espace de noms namespace.namespace2
:
namespace = window.namespace || {};
namespace.namespace2 = namespace.namespace2 || {};
namespace.namespace2.doSomeThing = function(){}
Ces deux fichiers peuvent vivre ensemble ou séparément sans se heurter.
Voici comment Stoyan Stefanov le fait dans son livre JavaScript Patterns que j'ai trouvé très bon (il montre également comment il le fait commentaires qui permettent la documentation de l'API générée automatiquement et comment ajouter une méthode au prototype d'un objet personnalisé):
/**
* My JavaScript application
*
* @module myapp
*/
/** @namespace Namespace for MYAPP classes and functions. */
var MYAPP = MYAPP || {};
/**
* A maths utility
* @namespace MYAPP
* @class math_stuff
*/
MYAPP.math_stuff = {
/**
* Sums two numbers
*
* @method sum
* @param {Number} a First number
* @param {Number} b Second number
* @return {Number} Sum of the inputs
*/
sum: function (a, b) {
return a + b;
},
/**
* Multiplies two numbers
*
* @method multi
* @param {Number} a First number
* @param {Number} b Second number
* @return {Number} The inputs multiplied
*/
multi: function (a, b) {
return a * b;
}
};
/**
* Constructs Person objects
* @class Person
* @constructor
* @namespace MYAPP
* @param {String} First name
* @param {String} Last name
*/
MYAPP.Person = function (first, last) {
/**
* First name of the Person
* @property first_name
* @type String
*/
this.first_name = first;
/**
* Last name of the Person
* @property last_name
* @type String
*/
this.last_name = last;
};
/**
* Return Person's full name
*
* @method getName
* @return {String} First name + last name
*/
MYAPP.Person.prototype.getName = function () {
return this.first_name + ' ' + this.last_name;
};
Il s'agit d'un suivi du lien de user106826 vers Namespace.js. Il semble que le projet soit passé à GitHub . C'est maintenant smith/namespacedotjs .
J'utilise ce simple assistant JavaScript pour mon petit projet et jusqu'à présent, il semble être assez léger et suffisamment polyvalent pour gérer le namespacing et le chargement de modules/classes. Ce serait génial si cela me permettait d'importer un paquet dans un espace de noms de mon choix, pas seulement dans un espace de noms global ... soupir, mais c'est tout.
Il vous permet de déclarer l’espace de nom puis de définir des objets/modules dans cet espace de nom:
Namespace('my.awesome.package');
my.awesome.package.WildClass = {};
Une autre option consiste à déclarer l'espace de noms et son contenu en une fois:
Namespace('my.awesome.package', {
SuperDuperClass: {
saveTheDay: function() {
alert('You are welcome.');
}
}
});
Pour plus d'exemples d'utilisation, consultez le fichier example.js dans la source .
J'utilise cette approche:
var myNamespace = {}
myNamespace._construct = function()
{
var staticVariable = "This is available to all functions created here"
function MyClass()
{
// Depending on the class, we may build all the classes here
this.publicMethod = function()
{
//Do stuff
}
}
// Alternatively, we may use a prototype.
MyClass.prototype.altPublicMethod = function()
{
//Do stuff
}
function privateStuff()
{
}
function publicStuff()
{
// Code that may call other public and private functions
}
// List of things to place publically
this.publicStuff = publicStuff
this.MyClass = MyClass
}
myNamespace._construct()
// The following may or may not be in another file
myNamespace.subName = {}
myNamespace.subName._construct = function()
{
// Build namespace
}
myNamespace.subName._construct()
Le code externe peut alors être:
var myClass = new myNamespace.MyClass();
var myOtherClass = new myNamepace.subName.SomeOtherClass();
myNamespace.subName.publicOtherStuff(someParameter);
Échantillon:
var namespace = {};
namespace.module1 = (function(){
var self = {};
self.initialized = false;
self.init = function(){
setTimeout(self.onTimeout, 1000)
};
self.onTimeout = function(){
alert('onTimeout')
self.initialized = true;
};
self.init(); /* If it needs to auto-initialize, */
/* You can also call 'namespace.module1.init();' from outside the module. */
return self;
})()
Vous pouvez éventuellement déclarer une variable local
, same
, comme self
, et affecter local.onTimeout
si vous souhaitez qu'elle soit privée.
Vous pouvez déclarer une fonction simple pour fournir des espaces de noms.
function namespace(namespace) {
var object = this, tokens = namespace.split("."), token;
while (tokens.length > 0) {
token = tokens.shift();
if (typeof object[token] === "undefined") {
object[token] = {};
}
object = object[token];
}
return object;
}
// Usage example
namespace("foo.bar").baz = "I'm a value!";
Si vous avez besoin de la portée privée:
var yourNamespace = (function() {
//Private property
var publicScope = {};
//Private property
var privateProperty = "aaa";
//Public property
publicScope.publicProperty = "bbb";
//Public method
publicScope.publicMethod = function() {
this.privateMethod();
};
//Private method
function privateMethod() {
console.log(this.privateProperty);
}
//Return only the public parts
return publicScope;
}());
yourNamespace.publicMethod();
sinon, si vous n'utilisez jamais la portée privée:
var yourNamespace = {};
yourNamespace.publicMethod = function() {
// Do something...
};
yourNamespace.publicMethod2 = function() {
// Do something...
};
yourNamespace.publicMethod();
J'ai créé namespace qui s'inspire des modules d'Erlang. C'est une approche très fonctionnelle, mais c'est comme ça que j'écris mon code JavaScript ces temps-ci.
Il donne à la fermeture un espace de noms global et expose un ensemble défini de fonctions dans cette fermeture.
(function(){
namespace("images", previous, next);
// ^^ This creates or finds a root object, images, and binds the two functions to it.
// It works even though those functions are not yet defined.
function previous(){ ... }
function next(){ ... }
function find(){ ... } // A private function
})();
Le modèle de module a été défini à l'origine comme un moyen de fournir une encapsulation à la fois privée et publique pour les classes d'ingénierie logicielle conventionnelle.
Lorsque vous travaillez avec le modèle Module, il peut s'avérer utile de définir un modèle simple que nous utilisons pour commencer à l'utiliser. En voici un qui couvre les variables d'espacement des noms, publiques et privées.
En JavaScript, le modèle de module est utilisé pour émuler davantage le concept de classes de manière à ce que nous puissions inclure à la fois des méthodes et des variables publiques/privées dans un seul objet, protégeant ainsi des parties particulières de la portée globale. Cela se traduit par une réduction de la probabilité que nos noms de fonctions soient en conflit avec d'autres fonctions définies dans des scripts supplémentaires sur la page.
var myNamespace = (function () {
var myPrivateVar, myPrivateMethod;
// A private counter variable
myPrivateVar = 0;
// A private function which logs any arguments
myPrivateMethod = function( foo ) {
console.log( foo );
};
return {
// A public variable
myPublicVar: "foo",
// A public function utilizing privates
myPublicFunction: function( bar ) {
// Increment our private counter
myPrivateVar++;
// Call our private method using bar
myPrivateMethod( bar );
}
};
})();
Avantages
pourquoi le modèle de module est-il un bon choix? Pour commencer, c'est beaucoup plus propre pour les développeurs issus d'un contexte orienté objet que l'idée d'une véritable encapsulation, du moins du point de vue de JavaScript.
Deuxièmement, il prend en charge les données privées - ainsi, dans le modèle Module, des parties publiques de notre code sont en mesure de toucher les parties privées, mais le monde extérieur est incapable de toucher aux parties privées de la classe.
Inconvénients
Les inconvénients du modèle de module sont que, lorsque nous accédons différemment aux membres publics et privés, lorsque nous souhaitons changer de visibilité, nous devons en fait modifier chaque endroit où le membre a été utilisé.
Nous ne pouvons pas non plus accéder aux membres privés dans les méthodes ajoutées ultérieurement à l'objet. Cela dit, dans de nombreux cas, le modèle de module est toujours très utile et, utilisé correctement, peut certainement améliorer la structure de notre application.
Le modèle de module révélateur
Maintenant que nous connaissons un peu mieux le pattern de module, passons à une version légèrement améliorée: le pattern Revealing Module de Christian Heilmann.
Heilmann était frustré par le fait qu'il devait répéter le nom de l'objet principal lorsque nous souhaitions appeler une méthode publique depuis une autre ou accéder à des variables publiques.Il a également détesté l'exigence du modèle Module s'opposer à la notation littérale pour les choses qu'il souhaitait rendre publiques.
Le résultat de ses efforts est un modèle mis à jour dans lequel nous définirions simplement toutes nos fonctions et variables dans la portée privée et renverrions un objet anonyme contenant des pointeurs vers la fonctionnalité privée que nous souhaitions révéler comme publique.
Vous trouverez ci-dessous un exemple d'utilisation du modèle de module de révélation
var myRevealingModule = (function () {
var privateVar = "Ben Cherry",
publicVar = "Hey there!";
function privateFunction() {
console.log( "Name:" + privateVar );
}
function publicSetName( strName ) {
privateVar = strName;
}
function publicGetName() {
privateFunction();
}
// Reveal public pointers to
// private functions and properties
return {
setName: publicSetName,
greeting: publicVar,
getName: publicGetName
};
})();
myRevealingModule.setName( "Paul Kinlan" );
Avantages
Ce modèle permet à la syntaxe de nos scripts d'être plus cohérente. Cela indique également à la fin du module quelles sont les fonctions et variables accessibles publiquement, ce qui facilite la lisibilité.
Inconvénients
Un inconvénient de ce modèle est que si une fonction privée fait référence à une fonction publique, cette fonction publique ne peut pas être remplacée si un correctif est nécessaire. En effet, la fonction privée continuera à faire référence à l'implémentation privée et le modèle ne s'applique pas aux membres publics, mais uniquement aux fonctions.
Les membres d'objets publics faisant référence à des variables privées sont également soumis aux remarques ci-dessus relatives aux règles de non-correctif.
J'utilise la syntaxe suivante pour l'espace de noms.
var MYNamespace = MYNamespace|| {};
MYNamespace.MyFirstClass = function (val) {
this.value = val;
this.getValue = function(){
return this.value;
};
}
var myFirstInstance = new MYNamespace.MyFirstClass(46);
alert(myFirstInstance.getValue());
jsfiddle: http://jsfiddle.net/rpaul/4dngxwb3/1/
J'ai 7 ans de retard à la fête, mais j'ai pas mal travaillé il y a 8 ans:
Il est important de pouvoir créer facilement et efficacement plusieurs espaces de noms imbriqués afin de garder une application Web complexe organisée et gérable, tout en respectant l'espace de noms JavaScript (empêchant la pollution des espaces de noms) et en évitant de surcharger les objets existants dans le chemin d'accès aux espaces de noms. .
De ce qui précède, voici ma solution circa-2008:
var namespace = function(name, separator, container){
var ns = name.split(separator || '.'),
o = container || window,
i,
len;
for(i = 0, len = ns.length; i < len; i++){
o = o[ns[i]] = o[ns[i]] || {};
}
return o;
};
Cela ne crée pas un espace de noms, mais fournit une fonction permettant de créer des espaces de noms.
Ceci peut être condensé en une ligne minifiée:
var namespace=function(c,f,b){var e=c.split(f||"."),g=b||window,d,a;for(d=0,a=e.length;d<a;d++){g=g[e[d]]=g[e[d]]||{}}return g};
Exemple d'utilisation:
namespace("com.example.namespace");
com.example.namespace.test = function(){
alert("In namespaced function.");
};
Ou, comme une déclaration:
namespace("com.example.namespace").test = function(){
alert("In namespaced function.");
};
Soit est ensuite exécuté comme:
com.example.namespace.test();
Si vous n'avez pas besoin de support pour les navigateurs hérités, une version mise à jour:
const namespace = function(name, separator, container){
var o = container || window;
name.split(separator || '.').forEach(function(x){
o = o[x] = o[x] || {};
});
return o;
};
Maintenant, je me méfierais d'exposer namespace
à l'espace de noms global lui-même. (Dommage que le langage de base ne nous le fournisse pas!) Donc, je l'utilisais généralement moi-même dans une fermeture, telle que:
(function(){
const namespace = function(name, separator, container){
var o = container || window;
name.split(separator || '.').forEach(function(x){
o = o[x] = o[x] || {};
});
return o;
};
const ns = namespace("com.ziesemer.myApp");
// Optional:
ns.namespace = ns;
// Further extend, work with ns from here...
}());
console.log("\"com\":", com);
Dans une application plus grande, cela n'a besoin d'être défini qu'une fois au début du chargement d'une page (pour les applications Web basées sur le client). Des fichiers supplémentaires peuvent alors réutiliser la fonction d'espace de noms s'ils sont conservés (inclus comme "optionnel" dans ce qui précède). Dans le pire des cas, si cette fonction est à nouveau déclarée plusieurs fois, il ne s'agit que de quelques lignes de code et moins si elle est réduite.
Après avoir porté plusieurs de mes bibliothèques dans différents projets et modifié constamment l’espace de noms de premier niveau (nommé de manière statique), je suis passé à l’utilisation de cette petite fonction d’assistance (open source) pour définir les espaces de noms.
global_namespace.Define('startpad.base', function(ns) {
var Other = ns.Import('startpad.other');
....
});
La description des avantages est à mon article de blog . Vous pouvez récupérer le code source ici .
L’un des avantages que j’aime vraiment est l’isolation entre les modules en ce qui concerne l’ordre de chargement. Vous pouvez vous référer à un module externe AVANT qu'il soit chargé. Et la référence d'objet que vous obtenez sera renseignée lorsque le code sera disponible.
Vous devez vérifier Namespace.js out!
J'aime la solution de Jaco Pretorius, mais je voulais rendre le mot-clé "this" un peu plus utile en le pointant sur l'objet module/namespace. Ma version de Skillet:
(function ($, undefined) {
console.log(this);
}).call(window.myNamespace = window.myNamespace || {}, jQuery);
Mon modèle préféré est devenu dernièrement ceci:
var namespace = (function() {
// expose to public
return {
a: internalA,
c: internalC
}
// all private
/**
* Full JSDoc
*/
function internalA() {
// ...
}
/**
* Full JSDoc
*/
function internalB() {
// ...
}
/**
* Full JSDoc
*/
function internalC() {
// ...
}
/**
* Full JSDoc
*/
function internalD() {
// ...
}
})();
Bien sûr, return peut être à la fin, mais si seules les déclarations de fonction le suivent, il est beaucoup plus facile de voir en quoi consiste l'espace de noms et quelle API est exposée.
Le modèle d'utilisation des expressions de fonction dans de tels cas empêche de savoir quelles méthodes sont exposées sans parcourir tout le code.
Nous pouvons l'utiliser indépendamment de cette manière:
var A = A|| {};
A.B = {};
A.B = {
itemOne: null,
itemTwo: null,
};
A.B.itemOne = function () {
//..
}
A.B.itemTwo = function () {
//..
}
Tout à fait un suivi de la réponse de Ionu Stan G. Stan, mais montrant les avantages d'un code non encombré en utilisant var ClassFirst = this.ClassFirst = function() {...}
, qui tire parti de la portée de fermeture de JavaScript pour réduire l'encombrement des espaces de noms dans le même espace de noms.
var Namespace = new function() {
var ClassFirst = this.ClassFirst = function() {
this.abc = 123;
}
var ClassSecond = this.ClassSecond = function() {
console.log("Cluttered way to access another class in namespace: ", new Namespace.ClassFirst().abc);
console.log("Nicer way to access a class in same namespace: ", new ClassFirst().abc);
}
}
var Namespace2 = new function() {
var ClassFirst = this.ClassFirst = function() {
this.abc = 666;
}
var ClassSecond = this.ClassSecond = function() {
console.log("Cluttered way to access another class in namespace: ", new Namespace2.ClassFirst().abc);
console.log("Nicer way to access a class in same namespace: ", new ClassFirst().abc);
}
}
new Namespace.ClassSecond()
new Namespace2.ClassSecond()
Sortie:
Cluttered way to access another class in namespace: 123
Nicer way to access a class in same namespace: 123
Cluttered way to access another class in namespace: 666
Nicer way to access a class in same namespace: 666
Je pense que vous utilisez tous trop de code pour un problème aussi simple. Pas besoin de faire un repo pour ça. Voici une fonction à une seule ligne.
namespace => namespace.split(".").reduce((last, next) => (last[next] = (last[next] || {})), window);
Essayez le:
// --- definition ---
const namespace = namespace => namespace.split(".").reduce((last, next) => (last[next] = (last[next] || {})), window);
// --- Use ----
let myNamespace = namespace("a.b.c");
myNamespace.MyClass = class MyClass {};
// --- see ----
console.log("a : ", a);
Si vous utilisez un Makefile, vous pouvez le faire.
// prelude.hjs
billy = new (
function moduleWrapper () {
const exports = this;
// postlude.hjs
return exports;
})();
// someinternalfile.js
function bob () { console.log('hi'); }
exports.bob = bob;
// clientfile.js
billy.bob();
De toute façon, je préfère utiliser un fichier Makefile une fois que je suis arrivé à environ 1000 lignes car je peux effectivement commenter de larges bandes de code en supprimant une seule ligne du fichier Make. Cela facilite les manipulations. De plus, avec cette technique, l'espace de nom n'apparaît qu'une seule fois dans le prélude. Il est donc facile de le modifier et vous n'avez pas à le répéter continuellement dans le code de la bibliothèque.
Un script Shell pour le développement en direct dans le navigateur utilisant un fichier makefile:
while (true); do make; sleep 1; done
Ajoutez ceci en tant que tâche 'make' 'et vous pouvez' vous y rendre 'pour garder votre version à jour au fur et à mesure que vous codez.
J'ai écrit une autre bibliothèque de nomspacing qui fonctionne un peu plus comme les packages/unités dans d'autres langues. Il vous permet de créer un package de code JavaScript et la référence de ce package à partir d'un autre code:
Package("hello", [], function() {
function greeting() {
alert("Hello World!");
}
// Expose function greeting to other packages
Export("greeting", greeting);
});
Package("example", ["hello"], function(greeting) {
// Greeting is available here
greeting(); // Alerts: "Hello World!"
});
Seul le deuxième fichier doit être inclus dans la page. Ses dépendances (fichier hello.js dans cet exemple) seront automatiquement chargées et les objets exportés à partir de ces dépendances seront utilisés pour renseigner les arguments du rappel. une fonction.
Vous pouvez trouver le projet associé dans Packages JS.
En JavaScript, il n'y a pas de méthodes prédéfinies pour utiliser les espaces de noms. En JavaScript, nous devons créer nos propres méthodes pour définir NameSpaces. Voici une procédure que nous suivons dans les technologies Oodles.
Enregistrer un espace de noms La fonction permettant d’enregistrer un espace de noms est la suivante
//Register NameSpaces Function
function registerNS(args){
var nameSpaceParts = args.split(".");
var root = window;
for(var i=0; i < nameSpaceParts.length; i++)
{
if(typeof root[nameSpaceParts[i]] == "undefined")
root[nameSpaceParts[i]] = new Object();
root = root[nameSpaceParts[i]];
}
}
Pour enregistrer un espace de noms, appelez simplement la fonction ci-dessus avec l'argument sous la forme d'un espace de noms séparé par '.'
(point). Par exemple, laissez le nom de votre application: oodles. Vous pouvez créer un espace de noms en suivant la méthode
registerNS("oodles.HomeUtilities");
registerNS("oodles.GlobalUtilities");
var $OHU = oodles.HomeUtilities;
var $OGU = oodles.GlobalUtilities;
Fondamentalement, il va créer votre structure NameSpaces comme ci-dessous dans le backend:
var oodles = {
"HomeUtilities": {},
"GlobalUtilities": {}
};
Dans la fonction ci-dessus, vous avez enregistré un espace de noms appelé "oodles.HomeUtilities"
et "oodles.GlobalUtilities"
. Pour appeler ces espaces de noms, nous créons une variable, à savoir var $OHU
et var $OGU
.
Ces variables ne sont qu'un alias d'Intializing de l'espace de noms. Maintenant, chaque fois que vous déclarerez une fonction appartenant à HomeUtilities
, vous la déclarerez comme suit:
$OHU.initialization = function(){
//Your Code Here
};
Ci-dessus, l'initialisation du nom de la fonction et celle-ci est placée dans un espace de noms $OHU
. et d'appeler cette fonction n'importe où dans les fichiers de script. Il suffit d'utiliser le code suivant.
$OHU.initialization();
De même, avec les autres espaces de noms.
J'espère que ça aide.
Mon habitude est d’utiliser la fonction myName () comme stockage de propriété, puis var myName comme détenteur de "méthode" ...
Que ce soit assez légitime ou non, battez-moi! Je me fie à ma logique PHP tout le temps, et les choses fonctionnent simplement. :RÉ
function myObj() {
this.prop1 = 1;
this.prop2 = 2;
this.prop3 = 'string';
}
var myObj = (
(myObj instanceof Function !== false)
? Object.create({
$props: new myObj(),
fName1: function() { /* code.. */ },
fName2: function() { /* code ...*/ }
})
: console.log('Object creation failed!')
);
if (this !== that) myObj.fName1(); else myObj.fName2();
Vous pouvez aussi le faire de manière "inversement" pour vérifier avant la création de l’objet qui est bien mieux :
function myObj() {
this.prop1 = 1;
this.prop2 = 2;
this.prop3 = 'string';
}
var myObj = (
(typeof(myObj) !== "function" || myObj instanceof Function === false)
? new Boolean()
: Object.create({
$props: new myObj(),
init: function () { return; },
fName1: function() { /* code.. */ },
fName2: function() { /* code ...*/ }
})
);
if (myObj instanceof Boolean) {
Object.freeze(myObj);
console.log('myObj failed!');
debugger;
}
else
myObj.init();
Référence à ceci: JavaScript: créer un objet avec Object.create ()