GAS图书馆的设计模式？ [英] Design patterns for libraries in GAS?

问题描述

我一直在试图找出编写GAS库的最佳方式，但我有一段时间可以搞清楚。我读道格拉斯克罗克福德的 - Javascript：好的部分，我试图在GAS中实施这些课程。每个导入的库都将全局变量添加到项目中（ScriptModule类型的），因此模块化设计模式似乎是一个开始的好地方。从文章中借用链接到这种模式的文章可能如下所示：

  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库开发了自己的健壮设计模式？

当您在GAS中导入脚本作为库时， 命名空间已经为它创建，所以你自己不需要或获得创建另一个。你必须尊重它，就像你所做的那样：

  //没有用于这个
 var module = LibName.MODULE; 
 var method = module.method; 
 
 //比较是否直接在库上编写代码
 var method1 = LibName.method1; 
  

GAS不是客户端JavaScript，您学习的大部分内容并不适用于Apps脚本，例如没有DOM，没有命名空间冲突，没有浏览器兼容性问题等。

顺便说一下，我认为这个对象嵌套结构甚至不适用于Apps脚本库。

I have been trying to figure out the best way to write GAS libraries for a while now but I have a hart time figuring it out. I read Douglas Crockford's - Javascript: The good parts and I'm trying to implement these lessons in GAS. Every imported library adds global variable to your project (of the ScriptModule type), so the modular design pattern seems like a good place to start. Borrowing from the article I linked to such a pattern might look like this:

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

    function privateMethod() {
        // ...
    }

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

    return my;
}());

This module could then be called like this:

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

From what I gather it is best have as few global variables as possible, so the general advice seems to be to save everything in one global variable. So the naming convention should then look something like this: LibName.PROJECT_NAME, where project name is the name of your single global variable which holds a module with everything else.

My goal here is to design secure, non-conflicting libraries. Am I right to use this design pattern? Has anyone developed their own robust design patterns for GAS libraries yet?

解决方案

When you import a script as a library in GAS a new "namespace" is already created for it, so there's no need or gain in creating another one yourself. You'd have have to "deference" it, like you did:

//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;

GAS is not client-side javascript, most of things you learn don't really apply to Apps Script, e.g. there's no DOM, no namespace conflict, no browser compatibility issues, etc.

By the way, I don't think this object nesting structure even works on Apps Script libraries.

这篇关于GAS图书馆的设计模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！