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

发布于 2024-12-06 20:20:40 字数 346 浏览 0 评论 0原文

另一个关于javascript 闭包的问题。我有一个全局“设置对象”。是在全局作用域的函数内使用它更好,还是在每次函数需要访问该对象时传递该对象更好?

为了更好地理解情况的一点模型这里

请忽略“baz()”也得到从闭包内的全局范围传递“foobar()”内的对象。您会发现两个版本都运行良好。

问题是,我每次都将函数需要工作的任何对象传递给每个函数(不必要的开销?),这可能很好并且易于阅读/理解,但我正在认真考虑改变这一点。缺点是我必须在“this”范围变得更深入时保留它,对吗?

感谢您的建议!

another question concerning javascricpt closures. I have a global "settings object". Is it better to use it from within functions in global scope or pass the object every time a function needs to access the object?

For a better understanding a little mockup of the situation here

Please ignore that "baz()" also gets the passed object within "foobar()" from the global scope within the closure. You see that both versions work fine.

The thing is that I am passing whatever object the function needs to work to every function and EVERY time (unneccesary overhead?), which might be nice and easy to read/understand but I am seriously thinking about changing this. Disadvantage would be that I have to keep the "this" scope wherever it gets deeper right?

Thanks for your advice!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

岁月无声 2024-12-13 20:20:40

您的设置对象不是全局,它是在闭包中定义的。

由于其目的是让闭包内的其他函数访问它,我想说直接访问该对象而不将其作为参数传递是 100% 好的。

FWIW,即使您确实将其作为参数传递,开销也可以忽略不计,因为仅传递对对象的引用,而不是整个对象的副本。

Your settings object isn't global, it's defined within a closure.

As the intent is that it be accessed by other function within the closure, I'd say you were 100% fine to just access that object directly and not pass it as a parameter.

FWIW, even if you did pass it as a parameter the overhead is negligible because only a reference to the object is passed, not a copy of the whole object.

べ映画 2024-12-13 20:20:40

因此,您基本上有三个选择:

  • 您希望将设置公开为全局变量,并由您的函数访问它,
  • 您希望将设置隐藏为实现细节并由您的函数访问它,
  • 您希望提供提供的可能性不同的设置对象具有不同的功能。

全局变量方法

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

也就是说,由于所有命名冲突,在 Javascript 中最好对所有全局变量进行“命名空间”。因此,您应该使用一个全局变量 MyGlobalNamespace,而不是全局变量 foobar,它是一个具有属性的对象:MyGlobalNamespace.fooMyGlobalNamespace.bar

私有变量方法

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

附加函数参数方法

基本上,如果您发现可以为不同的函数调用提供不同的设置,会有所收获。或者,也许您可​​以想象未来会有这样的收益。如果您的应用程序中有许多设置实例,那么这是显而易见的选择。

编辑

关于评论中的问题:

示例1)

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

示例2)

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

简而言之,我鼓励您阅读一些关于Javascript基本概念的好书。它有其特殊性,了解它们是件好事。

So you have basically three options:

  • You want to expose settings as a global variable, and have it accessed by your functions,
  • You want to hide settings as an implementation detail and have it accessed by your functions,
  • You want to give a possibility to supply different settings objects to different functions.

Global variable approach

Well, I guess it's a little bit like with any global variable. If settings is a singleton (for example it describes your application) and you can't see any benefit in having a possibility to call the same function with different settings objects, then I don't see why it couldn't be a global variable.

That said, because of all the naming conflicts, in Javascript it's good to "namespace" all the global variables. So instead of global variables foo and bar you should rather have one global variable MyGlobalNamespace which is an objects having attributes: MyGlobalNamespace.foo and MyGlobalNamespace.bar.

Private variable approach

Having a private variable accessed by a closure is a good pattern for hiding implementation details. If the settings object is something you don't want to expose as an API, this is probably the right choice.

Additional function parameter approach

Basically if you see a gain in having a possibility of supplying different settings to different function calls. Or perhaps if you can picture such gain in the future. Obvious choice if you have many instances of settings in your application.

EDIT

As to the question from the comments:

Example 1)

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

Example 2)

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

In a nutshell, I'd encourage you to read some good book on the fundamental concepts of Javascript. It has its paculiarities and it's good to know them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文