为什么立面模式+显露模块化模式“增加了安全性”？答案

【问题标题】：why does the facade pattern + revealing modular pattern "add security"?为什么立面模式+显露模块化模式“增加了安全性”？
【发布时间】：2015-01-16 15:05:27
【问题描述】：

REFERENCE

根据参考：下面是外观模式的更高级版本，为内部方法增加了安全性。

问题： 老实说，增加安全性是什么意思？此外，什么是不安全的例子？最后，security 和这种外观 + 显示模块模式的简单但真实的用例是什么？

var MyModule = ( function( window, undefined ) {

  // revealing module pattern ftw
  function MyModule() {

    function someMethod() {
      alert( 'some method' );
    }

    function someOtherMethod() {
      alert( 'some other method' );
    }

    // expose publicly available methods
    return {

      // in our normal revealing module pattern, we'd do the following:
      someMethod : someMethod,

      // in the facade pattern, we mask the internals so no one has direct access by doing this:
      // HOW DOES THIS MASK THE INTERNALS?  WHAT DO THEY MEAN BY ADDS SECURITY?
      someMethod : function() {
        someMethod();
      }

    };

  }

})(窗口);

【问题讨论】：

这意味着没有人可以更改函数签名。但是，它仍然可以完全替换，这使得整个想法有些愚蠢。如果它可以访问闭包，那么它就更有意义了。
等待显示模块模式，您可以重新分配 someMethod: 但是使用外观模式您不能重新分配 someMethod？
你能举一个实际的例子吗？我只是有点困惑。
你可以重新分配它。这有点没用，但我想在第二个中，您无法务实地获取方法源代码。不过，这几乎不是我所说的安全性。
问题是：什么样的安全性？可靠性？安全？保护？可编程性？还是用户保护？

标签： javascript design-patterns facade

【解决方案1】：

这毫无意义。真的没有。

没有添加“安全性”。在开发 Web 应用程序时，安全是一个完全不同的领域。
“与其他模式结合使用效果很好”、“易于实施”并不是真正的优势。正常的设计更简单。
“使修补内部结构变得容易”。当然。但是YAGNI。当您真正修补内部或填充外部时，您仍然可以引入它。
“提供更简单的公共接口”。嗯，它可以用来降低接口的复杂性，尤其是如果内部方法有额外的参数，这些参数没有记录在案并且预计不会暴露。但是示例中的someMethod 没有任何参数，所以这里只是没用。

实际上，显示模块模式本身已经是一个门面。它定义了一些内部函数，然后将它们导出到模块对象上，其属性名称为外部接口。不需要额外的间接层。

【讨论】：

寻找问题的解决方案。 “书”中的第一个例子是有道理的，上面那个，不是那么多......
很公平。你有这种模式的简单但清晰的例子吗？ @dandavis 你说第一个例子有意义吗？所以外观模式只是围绕一些条件（复杂性）包装一个函数？如果是这样，我可以继续前进……我明白了。
addEvent 比每次都编写 addEventListener 和 attachEvent 例程更容易、更安全。在这方面，您也可以将 polyfills 视为门面。
@MatthewHarwood：这不是将复杂的行为包装在一个函数中。首先是使用一个额外的名称（addEvent）而不是内部方法（addEventListener），即使它们正在做同样的事情（addEvent 可能是一个只调用addEventListener 的函数，但它也可以是addEvent = callable(Element.prototype.addEventListener) - 或者在模块模式中，声明someMethod: someInternalMethod）。关键是您可以轻松更改没有名称的实现。