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圖書館的設計模式？

回答

相關問題