GAS图书馆的设计模式？

我一直在努力想出一段时间写GAS库的最佳方式，但我有一个哈特时间计算出来。我读道格拉斯克罗克福德的 - Javascript：好的部分，我试图在GAS中实施这些课程。每个导入的库都将全局变量添加到您的项目中（ScriptModule类型的），因此the modular design pattern似乎是一个很好的开始。从我挂这样的模式的文章借用可能是这样的：GAS图书馆的设计模式？

var MODULE = (function() { 
    var my = {}, 
     privateVariable = 1; 

    function privateMethod() { 
     // ... 
    } 

    my.moduleProperty = 1; 
    my.moduleMethod = function() { 
     // ... 
    }; 

    return my; 
}());

该模块然后可以这样调用：

var module = LibName.MODULE; 
var property = module.moduleProperty; // 1 
var method = module.moduleMethod; // ...

从我所收集最好是尽可能少的全局变量尽可能，所以一般的建议似乎是将所有东西都保存在一个全局变量中。因此，命名约定应该看起来像这样：LibName.PROJECT_NAME，其中项目名称是您的单个全局变量的名称，该全局变量包含其他所有模块。

我的目标是设计安全，无冲突的库。我有权利使用这种设计模式吗？有没有人为GAS库开发了自己强大的设计模式呢？

来源

2012-11-27 M. Oranje

当您在GAS中导入脚本作为库时，已经为它创建了一个新的“名称空间”，因此您无需自行创建另一个名称空间。你必须要“尊重”了，像你这样：

//there's no purpose for this 
var module = LibName.MODULE; 
var method = module.method; 

//comparing if you write code directly on the library 
var method1 = LibName.method1;

气体不是客户端JavaScript，你最了解并不真正适用于Google Apps脚本，例如事没有DOM，没有名称空间冲突，没有浏览器兼容性问题等。

顺便说一句，我不认为这个对象嵌套结构甚至可以在Apps Script库上工作。

来源

2012-11-27 11:28:15

我认为你对冲突是正确的，图书馆的名字也是保存一切的名字空间。 –

（抱歉超过了5分钟的编辑限制）我测试了模块化模式，并按预期工作。在这种设计模式中，您将拥有一个只有对象本身才能访问的私有变量和私有方法的对象。有更好的方法来处理应用程序脚本中的对象吗？ –

我不认为有。但是，库脚本中的AFAIK变量/属性对导入它的脚本永远不可见。为了隐藏方法，你可以附加一个下划线“_”。再说一遍，我不认为将对象嵌套整个脚本只是将它用作库是有任何好处的。 –

GAS图书馆的设计模式？

回答

相关问题