Question

为模块模式手册构建最佳实践（针对内部的公司课程）我们需要轻松讨论公共合同和每个对象的持久性。所以团队分为两个结构：

CLASSIC：

// Namespace for the library
var myFunPattern1 = {};

// Library definition
myFunPattern1 = (function () {

    // Private variables / properties
    var myPrivateVar = "anyValue"

    // Private methods
        function anyPrivateMethod(parameter) {
            ...
            return "whatever";
         }

    // Public API
    return {
        anyPublicMethod: function (parameter) {
            ...
            return "whatever";
         }
    };
})();

其他：

// Namespace for the library
var myFunPattern2 = {};

// Library definition
myFunPattern2 = (function () {

     // Public API
     return {
        anyPublicMethod: internalNameForPublicMethod
    };

    // Private variables / properties
    var myPrivateVar = "anyValue"

    // Public methods
        function internalNameForPublicMethod(parameter) {
            ...
            return "whatever";
        }

    // Private methods
        function anyPrivateMethod(parameter) {
            ...
            return "whatever";
         }

})();

我们看到第一个更“代码优雅”，而第二个支持更快的开发和团队之间的清晰对话（一旦返回定义参数文档等等，每个开发人员可以开始处理其余的代码

另外，功能上的变化（即功能性能的A / B测试），第一模式需要更改功能，第二，只需要内部参考。甚至，这可能是动态完成的......

我们中的一些人认为第二种可能引起一些不一致并强制依赖（公共函数首先被声明，或者在声明之前被声明为invoque），其他人认为我们是安全的......

任何其他考虑因素??

返回JS Module Pattern上的结构

0 个答案: