GAS 라이브러리의 디자인 패턴은 무엇입니까?

Question

나는 GAS 라이브러리를 작성하는 가장 좋은 방법을 잠시 동안 알아 내려고 노력했지만 해트트를 알아 냈습니다. Douglas Crockford 's를 읽었습니다. Javascript : 좋은 부분들과 저는 GAS에서 이러한 수업을 구현하려고합니다. 가져온 모든 라이브러리는 (ScriptModule 유형의) 프로젝트에 전역 변수를 추가하므로 the modular design pattern은 시작하기 좋은 곳처럼 보입니다. 나는 그런 패턴에 링크 된 기사에서 차입하는 것은 다음과 같습니다

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, 여기서 project name은 다른 모든 것을 가진 모듈을 가지고있는 하나의 전역 변수의 이름입니다.

여기 내 목표는 안전하고 충돌이없는 라이브러리를 디자인하는 것입니다. 이 디자인 패턴을 사용할 권리가 있습니까? GAS 라이브러리를위한 강력한 디자인 패턴을 개발 한 사람이 있습니까?

Answer 1

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; 

가스는 클라이언트 측 자바 스크립트 아니다 당신이 정말로 애플리케이션 스크립트, 예를 들어, 적용되지 않습니다 배울 것들의 대부분 DOM, 네임 스페이스 충돌, 브라우저 호환성 문제 등이 없습니다.

그런데이 객체 중첩 구조는 Apps Script 라이브러리에서도 작동하지 않습니다.