Come faccio a creare uno spazio dei nomi in JavaScript in modo che i miei oggetti e le mie funzioni non vengano sovrascritti da altri oggetti e funzioni con lo stesso nome? Ho usato il seguente:

if (Foo == null || typeof(Foo) != "object") { var Foo = new Object();}

Esiste un modo più elegante o succinto di farlo?

Mi piace questo:

var yourNamespace = {

    foo: function() {
    },

    bar: function() {
    }
};

...

yourNamespace.foo();

Uso l'approccio trovato sul sito Enterprise jQuery :

Ecco il loro esempio che mostra come dichiarare proprietà e funzioni private e pubbliche. Tutto è fatto come una funzione anonima autoeseguente.

(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 ));

Quindi, se si desidera accedere a uno dei membri pubblici, basta andare skillet.fry()o skillet.ingredients.

La cosa davvero interessante è che ora puoi estendere lo spazio dei nomi usando la stessa sintassi esatta.

//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 ));

Il terzo undefinedargomento

Il terzo undefinedargomento è la fonte della variabile di valore undefined. Non sono sicuro che sia ancora rilevante oggi, ma mentre si lavora con browser / standard JavaScript più vecchi (ecmascript 5, javascript <1.8.5 ~ firefox 4), la variabile di portata globale undefinedè scrivibile, quindi chiunque potrebbe riscriverne il valore. Il terzo argomento (quando non viene passato un valore) crea una variabile denominata undefinedche è nell'ambito dello spazio dei nomi / funzione. Poiché durante la creazione dello spazio dei nomi non è stato passato alcun valore, il valore predefinito è il valore undefined.

Un altro modo per farlo, che considero un po 'meno restrittivo della forma letterale dell'oggetto, è questo:

var ns = new function() {

    var internalFunction = function() {

    };

    this.publicFunction = function() {

    };
};

Quanto sopra è praticamente simile al modello del modulo e, che ti piaccia o no , ti consente di esporre tutte le tue funzioni come pubbliche, evitando al contempo la struttura rigida di un oggetto letterale.

Esiste un modo più elegante o succinto di farlo?

Sì. Per esempio:

var your_namespace = your_namespace || {};

allora puoi avere

var your_namespace = your_namespace || {};
your_namespace.Foo = {toAlert:'test'};
your_namespace.Bar = function(arg) 
{
    alert(arg);
};
with(your_namespace)
{
   Bar(Foo.toAlert);
}

Normalmente lo costruisco in una chiusura:

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";
        }
    };
})();

Il mio stile nel corso degli anni ha avuto un sottile cambiamento da quando ho scritto questo, e ora mi ritrovo a scrivere la chiusura in questo modo:

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
    };
})();

In questo modo trovo l'API pubblica e l'implementazione più facili da capire. Pensa alla dichiarazione di ritorno come a un'interfaccia pubblica per l'implementazione.

Poiché puoi scrivere diversi file di JavaScript e successivamente combinarli o meno in un'applicazione, ognuno deve essere in grado di recuperare o costruire l'oggetto dello spazio dei nomi senza danneggiare il lavoro di altri file ...

Un file potrebbe voler usare lo spazio dei nomi namespace.namespace1:

namespace = window.namespace || {};
namespace.namespace1 = namespace.namespace1 || {};

namespace.namespace1.doSomeThing = function(){}

Un altro file potrebbe voler utilizzare lo spazio dei nomi namespace.namespace2:

namespace = window.namespace || {};
namespace.namespace2 = namespace.namespace2 || {};

namespace.namespace2.doSomeThing = function(){}

Questi due file possono vivere insieme o separati senza scontrarsi.

Ecco come Stoyan Stefanov lo fa nel suo libro JavaScript Patterns che ho trovato molto buono (mostra anche come fa commenti che consentono la documentazione API generata automaticamente e come aggiungere un metodo al prototipo di un oggetto personalizzato):

/**
* 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;
};

Uso questo approccio:

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()

Il codice esterno può quindi essere:

var myClass = new myNamespace.MyClass();
var myOtherClass = new myNamepace.subName.SomeOtherClass();
myNamespace.subName.publicOtherStuff(someParameter);

Questo è il seguito del link di user106826 a Namespace.js. Sembra che il progetto sia stato spostato su GitHub . Ora è smith / namespacedotjs .

Ho usato questo semplice aiuto JavaScript per il mio piccolo progetto e finora sembra essere leggero ma abbastanza versatile da gestire lo spazio dei nomi e il caricamento di moduli / classi. Sarebbe bello se mi permettesse di importare un pacchetto in uno spazio dei nomi di mia scelta, non solo nello spazio dei nomi globale ... sospiro, ma questo è anche il punto.

Ti permette di dichiarare lo spazio dei nomi e quindi definire oggetti / moduli in quello spazio dei nomi:

Namespace('my.awesome.package');
my.awesome.package.WildClass = {};

Un'altra opzione è dichiarare contemporaneamente lo spazio dei nomi e il suo contenuto:

Namespace('my.awesome.package', {
    SuperDuperClass: {
        saveTheDay: function() {
            alert('You are welcome.');
        }
    }
});

Per altri esempi di utilizzo, guarda il file example.js nel sorgente .

Campione:

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;
})()

Puoi facoltativamente dichiarare una localvariabile, samecome selfe assegnare local.onTimeoutse vuoi che sia privata.

È possibile dichiarare una semplice funzione per fornire spazi dei nomi.

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!";

Se è necessario l'ambito privato:

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();

altrimenti se non utilizzerai mai l'ambito privato:

var yourNamespace = {};

yourNamespace.publicMethod = function() {
    // Do something...
};

yourNamespace.publicMethod2 = function() {
    // Do something...
};

yourNamespace.publicMethod();

Il modello del modulo era originariamente definito come un modo per fornire incapsulamento sia pubblico che privato per le classi nell'ingegneria del software convenzionale.

Quando si lavora con il modello del modulo, potrebbe essere utile definire un modello semplice che utilizziamo per iniziare con esso. Eccone uno che copre le variabili di spaziatura, pubbliche e private.

In JavaScript, il modello del modulo viene utilizzato per emulare ulteriormente il concetto di classi in modo tale da poter includere sia metodi pubblici / privati ​​che variabili all'interno di un singolo oggetto, proteggendo in tal modo parti particolari dall'ambito globale. Ciò si traduce in una riduzione della probabilità che i nomi delle nostre funzioni siano in conflitto con altre funzioni definite in script aggiuntivi nella pagina.

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 );

    }
  };

})();

vantaggi

perché il modello del modulo è una buona scelta? Per i principianti, è molto più pulito per gli sviluppatori che provengono da un background orientato agli oggetti rispetto all'idea del vero incapsulamento, almeno dal punto di vista JavaScript.

In secondo luogo, supporta i dati privati, quindi, nel modello del modulo, le parti pubbliche del nostro codice sono in grado di toccare le parti private, tuttavia il mondo esterno non è in grado di toccare le parti private della classe.

svantaggi

Gli svantaggi del modello del modulo sono che quando accediamo ai membri sia pubblici che privati ​​in modo diverso, quando desideriamo modificare la visibilità, dobbiamo effettivamente apportare modifiche a ogni luogo in cui il membro è stato utilizzato.

Inoltre, non possiamo accedere ai membri privati ​​nei metodi che verranno aggiunti all'oggetto in un secondo momento . Detto questo, in molti casi il modello del modulo è ancora abbastanza utile e, se usato correttamente, ha sicuramente il potenziale per migliorare la struttura della nostra applicazione.

Il modello di modulo rivelatore

Ora che abbiamo un po 'più familiarità con il modello del modulo, diamo un'occhiata a una versione leggermente migliorata - il modello del modulo rivelatore di Christian Heilmann.

Il modello del modulo rivelatore è nato dal momento che Heilmann era frustrato dal fatto che doveva ripetere il nome dell'oggetto principale quando volevamo chiamare un metodo pubblico da un altro o accedere a variabili pubbliche e non gli piaceva il requisito del modello modulo per dover cambiare opporsi alla notazione letterale per le cose che desiderava rendere pubbliche.

Il risultato dei suoi sforzi è stato un modello aggiornato in cui avremmo semplicemente definito tutte le nostre funzioni e variabili nell'ambito privato e restituito un oggetto anonimo con puntatori alla funzionalità privata che desideravamo rivelare come pubblica.

Di seguito è riportato un esempio di come utilizzare il modello del modulo rivelatore

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" );

vantaggi

Questo modello consente alla sintassi dei nostri script di essere più coerente. Inoltre, rende più chiaro alla fine del modulo quali funzioni e variabili sono accessibili pubblicamente per facilitare la leggibilità.

svantaggi

Uno svantaggio di questo modello è che se una funzione privata fa riferimento a una funzione pubblica, tale funzione pubblica non può essere ignorata se è necessaria una patch. Questo perché la funzione privata continuerà a fare riferimento all'implementazione privata e il modello non si applica ai membri pubblici, ma solo alle funzioni.

I membri di oggetti pubblici che fanno riferimento a variabili private sono anche soggetti alle note sulla regola senza patch sopra.

Ho creato lo spazio dei nomi che si ispira ai moduli di Erlang. È un approccio molto funzionale, ma è così che scrivo il mio codice JavaScript in questi giorni.

Dà una chiusura uno spazio dei nomi globale ed espone un insieme definito di funzioni all'interno di quella chiusura.

(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

})();

Dopo aver portato diverse delle mie librerie su progetti diversi e aver dovuto cambiare costantemente lo spazio dei nomi di livello superiore (staticamente denominato), sono passato all'utilizzo di questa piccola funzione di supporto (open source) per definire gli spazi dei nomi.

global_namespace.Define('startpad.base', function(ns) {
    var Other = ns.Import('startpad.other');
    ....
});

La descrizione dei vantaggi è nel mio post sul blog . Puoi prendere il codice sorgente qui .

Uno dei vantaggi che mi piace molto è l'isolamento tra i moduli rispetto all'ordine di caricamento. È possibile fare riferimento a un modulo esterno PRIMA che sia caricato. E il riferimento all'oggetto che otterrai sarà compilato quando il codice sarà disponibile.

Uso la sintassi seguente per lo spazio dei nomi.

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/

Sono in ritardo di 7 anni alla festa, ma ho lavorato parecchio 8 anni fa:

• http://blogger.ziesemer.com/2008/05/javascript-namespace-function.html
• http://blogger.ziesemer.com/2007/10/respecting-javascript-global-namespace.html

È importante essere in grado di creare in modo semplice ed efficiente più spazi dei nomi nidificati per mantenere organizzata e gestibile un'applicazione web complessa, rispettando lo spazio dei nomi globale JavaScript (prevenendo l'inquinamento dello spazio dei nomi) e senza ostruire oggetti esistenti nel percorso dello spazio dei nomi .

Da quanto sopra, questa era la mia soluzione intorno al 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;
};

Questo non sta creando uno spazio dei nomi, ma fornisce una funzione per la creazione di spazi dei nomi.

Questo può essere condensato in un one-liner minimizzato:

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};

Esempio di utilizzo:

namespace("com.example.namespace");
com.example.namespace.test = function(){
  alert("In namespaced function.");
};

Oppure, come una sola affermazione:

namespace("com.example.namespace").test = function(){
  alert("In namespaced function.");
};

Entrambi vengono quindi eseguiti come:

com.example.namespace.test();

Se non hai bisogno di supporto per i browser legacy, una versione aggiornata:

const namespace = function(name, separator, container){
    var o = container || window;
    name.split(separator || '.').forEach(function(x){
        o = o[x] = o[x] || {};
    });
    return o;
};

Ora, sarei diffidente di esporre namespaceallo spazio dei nomi globale stesso. (Peccato che la lingua di base non ci fornisca questo!) Quindi di solito lo uso da solo in una chiusura, come ad esempio:

(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);

In un'applicazione più grande, questo deve essere definito solo una volta all'inizio del caricamento di una pagina (per app Web basate su client). File aggiuntivi possono quindi riutilizzare la funzione dello spazio dei nomi se mantenuta (inclusa come "opzionale" in precedenza). Nel peggiore dei casi, se questa funzione viene ripetuta alcune volte, è solo poche righe di codice e meno se minimizzata.

Penso che tutti voi usiate troppo codice per un problema così semplice. Non c'è bisogno di fare un repository per quello. Ecco una funzione a linea singola.

namespace => namespace.split(".").reduce((last, next) => (last[next] = (last[next] || {})), window);

Provalo :

// --- 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);

Mi piace la soluzione di Jaco Pretorius, ma volevo rendere la parola chiave "this" un po 'più utile puntandola sull'oggetto module / namespace. La mia versione di padella:

(function ($, undefined) {

    console.log(this);

}).call(window.myNamespace = window.myNamespace || {}, jQuery);

Il mio modello preferito è diventato ultimamente questo:

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() {
    // ...
  }
  
})();

Ovviamente, il ritorno può essere alla fine, ma se solo le dichiarazioni di funzioni lo seguono, è molto più facile vedere di cosa tratta lo spazio dei nomi e quale API è esposta.

Il modello di utilizzo delle espressioni di funzione in questi casi si traduce nel non essere in grado di sapere quali metodi sono esposti senza andare oltre l'intero codice.

Se usi un Makefile puoi farlo.

// 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();

Preferisco usare un Makefile comunque una volta arrivato a circa 1000 righe perché posso effettivamente commentare ampie strisce di codice rimuovendo una singola riga nel makefile. Rende facile giocherellare con le cose. Inoltre, con questa tecnica lo spazio dei nomi appare solo una volta nel preludio, quindi è facile da cambiare e non è necessario continuare a ripeterlo all'interno del codice della libreria.

Uno script di shell per lo sviluppo live nel browser quando si utilizza un makefile:

while (true); do make; sleep 1; done

Aggiungi questo come compito make 'go' e puoi 'make go' per mantenere la tua build aggiornata mentre digiti.

Piuttosto un seguito della risposta di Ionuț G. Stan, ma mostrando i vantaggi del codice ordinato usando var ClassFirst = this.ClassFirst = function() {...}, che sfrutta l'ambito di chiusura di JavaScript per un minore ingombro dello spazio dei nomi per le classi nello stesso spazio dei nomi.

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()

Produzione:

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

Ho scritto un'altra libreria di namespace che funziona un po 'di più come fanno i pacchetti / unità in altre lingue. Ti consente di creare un pacchetto di codice JavaScript e il riferimento a quel pacchetto da un altro codice:

File hello.js

Package("hello", [], function() {
  function greeting() {
    alert("Hello World!");
  }
  // Expose function greeting to other packages
  Export("greeting", greeting);
});

File Example.js

Package("example", ["hello"], function(greeting) {
  // Greeting is available here
  greeting();  // Alerts: "Hello World!"
});

Solo il secondo file deve essere incluso nella pagina. Le sue dipendenze (file hello.js in questo esempio) verranno caricate automaticamente e gli oggetti esportati da tali dipendenze verranno utilizzati per popolare gli argomenti della funzione di callback.

È possibile trovare il progetto correlato in Pacchetti JS .

Possiamo usarlo indipendentemente in questo modo:

var A = A|| {};
A.B = {};

A.B = {
    itemOne: null,
    itemTwo: null,
};

A.B.itemOne = function () {
    //..
}

A.B.itemTwo = function () {
    //..
}

La mia abitudine è quella di utilizzare la funzione myName () come archivio di proprietà, quindi var myName come "metodo" titolare ...

Che sia abbastanza legittimo o no, picchiami! Mi affido sempre alla mia logica PHP e le cose funzionano semplicemente. : D

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();

Puoi anche farlo in un modo 'viceversa' per verificare prima della creazione dell'oggetto che è molto meglio :

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();

Riferimento a questo: JavaScript: creazione di oggetto con Object.create ()

In JavaScript non ci sono metodi predefiniti per usare gli spazi dei nomi. In JavaScript dobbiamo creare i nostri metodi per definire NameSpaces. Ecco una procedura che seguiamo nelle tecnologie Oodles.

Registrare uno spazio dei nomi Di seguito è la funzione per registrare uno spazio dei nomi

//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]];
 }
}

Per registrare uno spazio dei nomi basta chiamare la funzione sopra con l'argomento come spazio dei nomi separato da '.'(punto). Ad esempio Lascia che il nome dell'applicazione sia oodles. Puoi creare uno spazio dei nomi seguendo il metodo

registerNS("oodles.HomeUtilities");
registerNS("oodles.GlobalUtilities");
var $OHU = oodles.HomeUtilities;
var $OGU = oodles.GlobalUtilities;

Fondamentalmente creerà la tua struttura NameSpaces come sotto nel backend:

var oodles = {
    "HomeUtilities": {},
    "GlobalUtilities": {}
};

Nella funzione sopra hai registrato uno spazio dei nomi chiamato "oodles.HomeUtilities"e "oodles.GlobalUtilities". Per chiamare questi spazi dei nomi facciamo una variabile cioè var $OHUe var $OGU.

Queste variabili non sono altro che un alias per l'Intializzazione dello spazio dei nomi. Ora, ogni volta che dichiari una funzione che ti appartiene HomeUtilitiesla dichiarerai come segue:

$OHU.initialization = function(){
    //Your Code Here
};

Sopra è l'inizializzazione del nome della funzione e viene inserita in uno spazio dei nomi $OHU. e chiamare questa funzione ovunque nei file di script. Usa solo il seguente codice.

$OHU.initialization();

Allo stesso modo, con un altro NameSpaces.

Spero che sia d'aiuto.

JavaScript non supporta lo spazio dei nomi per impostazione predefinita. Quindi, se si crea qualsiasi elemento (funzione, metodo, oggetto, variabile), diventa globale e inquina lo spazio dei nomi globale. Facciamo un esempio di definizione di due funzioni senza spazio dei nomi,

function func1() {
    console.log("This is a first definition");

}
function func1() {
    console.log("This is a second definition");
}
func1(); // This is a second definition

Chiama sempre la seconda definizione della funzione. In questo caso, lo spazio dei nomi risolverà il problema della collisione dei nomi.