JavaScript闭包使用全局设置对象或将其传递给每个函数

关于javascricpt闭包的另一个问题。我有一个全局“设置对象”。是从全局范围内的函数中使用它更好，还是每次函数需要访问对象时都传递对象更好

为了更好地理解这种情况，我们制作了一个小模型

请忽略“baz（）”还从闭包中的全局作用域获取“foobar（）”中传递的对象。您可以看到这两个版本都很好地工作

问题是，我每次都将函数需要工作的任何对象传递给每个函数（不必要的开销？），这可能很好，也很容易阅读/理解，但我正在认真考虑改变这一点。缺点是我必须在“这个”范围变得更深的地方保留它，对吗

---

谢谢你的建议

所以您基本上有三种选择：

• 您希望将设置公开为全局变量，并让函数访问它
• 您希望将设置隐藏为实现细节，并让您的函数访问它
• 您希望能够为不同的功能提供不同的设置对象

全局变量方法

我想这有点像任何全局变量。如果设置是一个单例（例如，它描述了您的应用程序），并且您看不到使用不同的设置对象调用同一函数的任何好处，那么我不明白为什么它不能成为全局变量

这就是说，由于所有的命名冲突，在Javascript中最好将所有全局变量“名称空间”。因此，与其使用全局变量

foo

和

bar

，不如使用一个全局变量

MyGlobalNamespace

，它是一个具有以下属性的对象：

MyGlobalNamespace.foo

和

MyGlobalNamespace.bar

私有变量方法

让闭包访问私有变量是隐藏实现细节的好模式。如果设置对象是您不想作为API公开的对象，那么这可能是正确的选择

附加功能参数方法

基本上，如果您看到为不同的函数调用提供不同设置的可能性会有所增加。或者，如果你能想象未来会有这样的收获。如果应用程序中有多个设置实例，那么这是一个明显的选择

编辑

关于评论中的问题：

例1）

var blah=123；
函数fizbuzz（）{
console.log（blah）；//您的设置对象不是全局的，它是在闭包中定义的

由于其目的是让闭包中的其他函数可以访问该对象，因此我认为您完全可以直接访问该对象，而不将其作为参数传递

FWIW，即使您确实将其作为参数传递，开销也可以忽略不计，因为只传递了对对象的引用，而不是整个对象的副本。
谈论名称空间js vars：我确实为闭包本身命名了名称空间。您编写了名称空间“foo”和“bar”。我认为您的意思只是“foo”，对吗？因为“bar”、“baz”和“foobar”只是“private”函数，闭包内的任何函数都不需要命名空间？另外，我可以确保始终使用“this”来调用闭包内的变量，对吗？这是另一件事，我可以使用“this.settings”或“setting”，但第一个确保我访问闭包内的变量（可能是另一个潜伏在某处的全局“设置”变量）例如，我的
foo
和
bar
与你的
foo
和
bar
@junior没有任何关系。我绝对同意这个答案：。这本书很棒，他在网上也有讲座。
var blah = 123;

function fizbuzz() {
    console.log(blah); // <-- This is an example of a closure accessing 
                       // a variable
    console.log(this.blah); // <-- Most likely makes no sense. It might work, 
                            // because by default this will be set to a global 
                            // object named window, but this is probably not 
                            // what you want. In other situations this might 
                            // point to another object.
}

var obj = {

    blah: 123,

    fizbuzz: function() {
        console.log(this.blah); // <-- This is *NOT* an example of a closure
                                // accessing a private variable. It's rather the
                                // closest Javascript can get to accessing an
                                // instance variable by a method, though this 
                                // terminology shouldn't be used.
        console.log(blah); // <-- This MAKES NO SENSE, there is no variable blah 
                           // accessible from here.
    }
};