带有示例的 JavaScript 模块模式 [关闭]

Posted 2023-03-08

【中文标题】带有示例的 JavaScript 模块模式 [关闭]

【英文标题】：JavaScript module pattern with example [closed]

【发布时间】：2013-07-20 13:26:42

【问题描述】：

我找不到任何可访问的示例来说明两个（或更多）不同的模块如何连接在一起工作。

所以，我想问一下是否有人有时间编写一个示例来解释模块如何协同工作。

【问题讨论】：

这一切在过去四年中都发生了变化，但由于过度节制，这些过时的信息将永远存在。这是 ES6 模块上的 MDN's page。

【参考方案1】：

为了接近模块化设计模式，您需要先了解这些概念：

立即调用函数表达式 (IIFE)：

(function() 
      // Your code goes here 
());

您可以通过两种方式使用这些功能。 1. 函数声明 2. 函数表达式。

这里是使用函数表达式。

什么是命名空间？ 现在，如果我们将命名空间添加到上面的代码中，那么

var anoyn = (function() 
());

什么是 JS 中的闭包？

这意味着如果我们在另一个函数中声明任何具有任何变量范围的函数（在 JS 中我们可以在另一个函数中声明一个函数！），那么它将始终计算该函数范围。这意味着将始终读取外部函数中的任何变量。它不会读取同名的全局变量（如果有的话）。这也是使用模块化设计模式避免命名冲突的目的之一。

var scope = "I am global";
function whatismyscope() 
    var scope = "I am just a local";
    function func() return scope;
    return func;

whatismyscope()()

现在我们将应用我上面提到的这三个概念来定义我们的第一个模块化设计模式：

var modularpattern = (function() 
    // your module code goes here
    var sum = 0 ;

    return 
        add:function() 
            sum = sum + 1;
            return sum;
        ,
        reset:function() 
            return sum = 0;    
          
       
());
alert(modularpattern.add());    // alerts: 1
alert(modularpattern.add());    // alerts: 2
alert(modularpattern.reset());  // alerts: 0

jsfiddle for the code above.

目标是向外界隐藏变量可访问性。

希望这会有所帮助。祝你好运。

【讨论】：

为 iife 命名会更好吗？出于语义目的和更好的堆栈跟踪？它会改变代码中的任何内容吗？

您的第一个示例 (function() /* Your code goes here */()); 实际上是一个 IIFE（立即调用函数表达式），好吧它是匿名的，因为它没有名称，所以您甚至可能想称它为 IIAFE（立即调用匿名函数表达式）在***.com/questions/2421911/…上查看更多关于 IIFE 的信息

为什么使用了return语句？如果我们省略 return 那么 add 和 reset 函数将是公共的，我猜他们可以访问局部变量 sum ？我说的对吗？

你的第二个例子看起来像一个对象或者我不对？

这并没有解决 OP 的问题。它是对模块模式的描述，而不是多个模块如何按照 OP 的要求协同工作的示例。

【参考方案2】：

在这里https://toddmotto.com/mastering-the-module-pattern 你可以找到详细解释的模式。我要补充一点，关于模块化 javascript 的第二件事是如何在多个文件中构建代码。很多人可能会建议您在这里使用 AMD，但我可以根据经验说，由于大量 HTTP 请求，您最终会在某些时候页面响应缓慢。出路是将您的 JavaScript 模块（每个文件一个）预编译为遵循 CommonJS 标准的单个文件。在这里查看示例http://dsheiko.github.io/cjsc/

【讨论】：

所有 AMD 实现还提供预编译到单个文件中。

没错，但是生成的优化文件需要加载器库（刚刚用r.js v2.1.14重新检查过），这通常很重。一旦我们编译了代码，我们就不需要解析异步加载的依赖项，我们不需要这个库。试想一下：我们将模块包装到 AMD 中，这意味着异步。加载，然后将它们编译成一个文件（不再单独加载），但加载整个库以解决它们（现在是多余的）。对我来说，这听起来不是最佳方式。当我们不异步加载时，为什么还要 AMD？

almond.js 为完成的生产代码提供了比 RequireJS 更小的重量加载器，但相对而言，不发出单个 http 请求的性能优势远远超过将加载器代码添加到模块的成本，所以虽然它不是最理想的，但它的规模要小得多。在我看来，这个问题应该转过来——为什么在浏览器不同步的情况下假设同步？我实际上认为 RequireJS 和 CommonJS 都应该内置一个 Promise 实现。

两种格式都是 CommonJS Modules/2.0 的有效路径，并提供相同的可扩展性。对我来说 - 处理 CJS Modules/1.1（这就是我所说的 CommonJS）要容易得多，代码看起来更干净。

我遇到了 AMD 的以下好处： * 不仅可以加载 JavaScript 文件； * 路径别名；好吧，CommonJS Compiler 解决了这些问题——它将非 JavaScipt/JSON 依赖项加载为数据，并且可以提供构建配置（包括别名）。唯一的缺点是它需要建造。但是现在每个人都在为 CSS 预处理器构建项目。所以它只是为 Grunt/Gulp 添加一个额外的任务......

【参考方案3】：

你可以在这里找到模块模式 JavaScript http://www.sga.su/module-pattern-javascript/

【参考方案4】：

我想通过讨论如何将模块组合到应用程序中来扩展上述答案。我在 doug crockford 的书中读到过这方面的内容，但对于 javascript 来说，这一切仍然有点神秘。

我来自 c# 背景，因此添加了一些我认为有用的术语。

HTML

您将拥有某种*** html 文件。将其视为您的项目文件会有所帮助。您添加到项目中的每个 javascript 文件都想进入这个，不幸的是，您没有获得对此的工具支持（我正在使用 IDEA）。

您需要使用以下脚本标签将文件添加到项目中：

        <script type="text/javascript" src="app/native/MasterFile.js" /></script>
        <script type="text/javascript" src="app/native/SomeComponent.js" /></script>

看起来折叠标签会导致事情失败 - 虽然它看起来像 xml，但它确实是一些更疯狂的规则！

命名空间文件

MasterFile.js

myAppNamespace = ;

就是这样。这只是为我们的其余代码添加一个全局变量。您也可以在此处（或在它们自己的文件中）声明嵌套命名空间。

模块

SomeComponent.js

myAppNamespace.messageCounter= (function()

    var privateState = 0;

    var incrementCount = function () 
        privateState += 1;
    ;

    return function (message) 
        incrementCount();
        //TODO something with the message! 
    
)();

我们在这里所做的是将消息计数器函数分配给我们应用程序中的变量。这是一个返回我们立即执行的函数的函数。

概念

我认为将 SomeComponent 中的第一行视为您要声明某些内容的命名空间会有所帮助。唯一需要注意的是，您的所有命名空间都需要首先出现在其他文件中 - 它们只是由我们的应用程序变量根植的对象。

目前我只采取了一些小步骤（我正在从 extjs 应用程序中重构一些普通的 javascript，以便我可以对其进行测试）但它看起来相当不错，因为您可以定义小的功能单元同时避免陷入泥潭'this'。

您还可以使用这种风格来定义构造函数，方法是返回一个函数，该函数返回一个包含函数集合的对象，而不是立即调用它。

【讨论】：

谢谢！非常有帮助

【参考方案5】：

我真的会推荐任何进入这个主题的人阅读 Addy Osmani 的免费书籍：

“学习 JavaScript 设计模式”。

http://addyosmani.com/resources/essentialjsdesignpatterns/book/

当我开始编写更易于维护的 JavaScript 时，这本书给了我很大的帮助，我仍然将它用作参考。看看他不同的模块模式实现，他解释得很好。

【讨论】：

我还建议阅读我关于“最终模块模式”的文章，这在 Addy Osmani 的书中没有介绍：github.com/tfmontague/definitive-module-pattern

这与 Stoyan Stefanov 的“JavaScript 模式”相比如何

斯托扬的书要全面得多。它不仅涵盖高级模式，还更深入地讨论了其他 JS 最佳实践。

对“学习 JavaScript 设计模式”的评论amazon.com/product-reviews/1449331815

Stoyan Stefanov amazon.com/product-reviews/0596806752 对“JavaScript 模式”的评论。注意：这似乎比“学习 JavaScript 设计模式”中的要好得多