模块设计模式封装

Question

给定模块设计模式中的代码：

​

    var HTMLChanger = (function() {
      var contents = 'contents'
    
      var changeHTML = function() {
        var element = document.getElementById('attribute-to-change');
        element.innerHTML = contents;
      }
    
      return {
        callChangeHTML: function() {
          changeHTML();
          console.log(contents);
        }
      };
    
    })();
    
    HTMLChanger.callChangeHTML();       // Outputs: 'contents'
    console.log(HTMLChanger.contents);  // undefined

<div id="attribute-to-change"></div>

​

我们有这条线：

console.log(HTMLChanger.contents);  // undefined

如果我们有一个代码给我们另一个结果呢：

console.log(HTMLChanger.contents);  // 'contents'

与其相关的前一行和模块设计模式代码有什么好处？

Answer 1

console.log(HTMLChanger.contents); // undefined

您的HTMLChanger变量被分配给IIFE的返回值(立即调用函数表达式)。返回值在这里：

  return {
    callChangeHTML: function() {
      changeHTML();
      console.log(contents);
    }
  };

因此，它被设置为包含一个名为callChangeHTML的属性的对象。变量contents和changeHTML仅在IIFE的作用域中定义，而不是返回对象的属性(否则，它将违背此模式的目的，即隐藏实现细节)。除非您向返回的对象添加更多的函数(如getter和setter)，否则IIFE之外的代码绝对无法访问它们。看起来是这样的：

​

    var HTMLChanger = (function() {
      var contents = 'contents' //this is just a variable! not a property!
    
      var changeHTML = function() {
        var element = document.getElementById('attribute-to-change');
        element.innerHTML = contents;
      }
    
      return {
        callChangeHTML: function() {
          changeHTML();
          console.log(contents);
        },
        getContents: function() {
          return contents;
        }
      };
    
    })();
    
    HTMLChanger.callChangeHTML();       // Outputs: 'contents'
    console.log(HTMLChanger.getContents());  // Also outputs 'contents'

<div id="attribute-to-change"></div>

​

前面的行和模块设计模式代码的好处是什么？

将实现隐藏在函数之外的代码无法访问的地方，并且只公开包含要与实现交互的函数的接口。换句话说，这是一种创建“黑匣子”的方法，该“黑匣子”上只有一组选定的函数，而不是许多函数和变量，这些函数和变量很可能永远不会在实现外部的上下文中使用，例如模块之外的其他代码。