模块设计模式封装
Module design pattern encapsulation
给定模块设计模式中的代码:
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'
上一行和与之相关的模块设计模式代码有什么好处?
console.log(HTMLChanger.contents); // undefined
您的 HTMLChanger 变量已分配给 IIFE(立即调用的函数表达式)的 return 值。 return 值在这里:
return {
callChangeHTML: function() {
changeHTML();
console.log(contents);
}
};
因此它被设置为包含一个名为 callChangeHTML
的 属性 的对象。变量 contents
和 changeHTML
仅在 IIFE 的范围内定义,而不是 returned 对象的属性(否则,它会破坏此模式的目的,即隐藏实施细节)。 IIFE 之外的代码绝对无法访问它们,除非您向 returned 对象添加更多函数,如 getter 和 setter。那看起来像这样:
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>
What is the benefit of previous line and module design pattern code assotiated with it?
您将 实现 隐藏在函数之外的任何代码都无法访问它的地方,并且您只公开一个 接口 其中包含函数与实现交互。换句话说,这是一种创建 "black box" 的方法,它上面只有一组 select 函数,而不是许多您可能永远不会在外部上下文中使用的函数和变量实现,例如模块外的其他代码。
给定模块设计模式中的代码:
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'
上一行和与之相关的模块设计模式代码有什么好处?
console.log(HTMLChanger.contents); // undefined
您的 HTMLChanger 变量已分配给 IIFE(立即调用的函数表达式)的 return 值。 return 值在这里:
return {
callChangeHTML: function() {
changeHTML();
console.log(contents);
}
};
因此它被设置为包含一个名为 callChangeHTML
的 属性 的对象。变量 contents
和 changeHTML
仅在 IIFE 的范围内定义,而不是 returned 对象的属性(否则,它会破坏此模式的目的,即隐藏实施细节)。 IIFE 之外的代码绝对无法访问它们,除非您向 returned 对象添加更多函数,如 getter 和 setter。那看起来像这样:
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>
What is the benefit of previous line and module design pattern code assotiated with it?
您将 实现 隐藏在函数之外的任何代码都无法访问它的地方,并且您只公开一个 接口 其中包含函数与实现交互。换句话说,这是一种创建 "black box" 的方法,它上面只有一组 select 函数,而不是许多您可能永远不会在外部上下文中使用的函数和变量实现,例如模块外的其他代码。