<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>JavaScript Module Pattern &#8211; Turbosite &#8211; Blog</title>
	<atom:link href="https://www.turbosite.com.br/blog/tag/javascript-module-pattern/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.turbosite.com.br/blog</link>
	<description></description>
	<lastBuildDate>Fri, 07 Nov 2014 11:51:28 +0000</lastBuildDate>
	<language>pt-BR</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.2</generator>

<image>
	<url>https://www.turbosite.com.br/blog/wp-content/uploads/2026/09/cropped-logo_turbo_vermelha-32x32.png</url>
	<title>JavaScript Module Pattern &#8211; Turbosite &#8211; Blog</title>
	<link>https://www.turbosite.com.br/blog</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>JavaScript e Padrão de Módulo</title>
		<link>https://www.turbosite.com.br/blog/javascript-e-padrao-de-modulo/</link>
		
		<dc:creator><![CDATA[turboajuda]]></dc:creator>
		<pubDate>Fri, 07 Nov 2014 11:51:28 +0000</pubDate>
				<category><![CDATA[Dicas]]></category>
		<category><![CDATA[Javascript]]></category>
		<category><![CDATA[javascript avancado]]></category>
		<category><![CDATA[JavaScript Module Pattern]]></category>
		<category><![CDATA[JavaScript Padrão de Módulo]]></category>
		<guid isPermaLink="false">http://blog.turbosite.com.br/?p=3703</guid>

					<description><![CDATA[A equipe da Turbosite repassa seu conhecimento sobre JavaScript Module Pattern (Padrão de Módulo), abrangendo deste o estudo básico ao avançado desse padrão.]]></description>
										<content:encoded><![CDATA[<p>Continuando a postagem anterior <a title="JavaScript IIFE como contêiner de códigos" href="https://www.turbosite.com.br/blog/javascript-iife-como-conteiner-de-codigos/">JavaScript IIFE como contêiner de códigos</a>, compartilhamos aqui mais um artigo do blog <a href="http://desenvolvimentoparaweb.com/javascript/javascript-module-pattern-padrao-modulo/">Desenvolvimento Para Web</a>. A equipe da <a href="https://www.turbosite.com.br/">Turbosite</a> repassa seu conhecimento sobre <strong class="single__fake-title">JavaScript Module Pattern (Padrão de Módulo)</strong>, um padrão de desenvolvimento bastante comum para Javascript. As próximas linhas abaixo abrangem deste o estudo básico ao avançado desse padrão.</p>
<p>&nbsp;</p>
<h2>Anonymous Closures (Closures Anônimos)</h2>
<p><strong>Anonymous Closures</strong> são o construto fundamental em Module Pattern que tornam tudo isso possível e são uma das melhores característica de JavaScript: é possível criar uma função anônima e executá-la imediatamente. Todo o código que é executado dentro da função esta no escopo do closure (algo como “fechamento”), o que proporciona privacidade e estado durante toda a vida da aplicação.</p>
<div class="wp_syntax">
<pre class="lang:js decode:true">(function () {
    // Todas variáveis e funções estão somente neste escopo
    // e ainda mantêm acesso a todos os globais
}());</pre>
</div>
<p>Observe a <code>()</code> em torno da função anônima. Isto é requerido pela linguagem, uma vez que declarações que começam com a função de token são sempre considerados declarações de função. Incluir <code>()</code> cria uma expressão de função.</p>
<p>&nbsp;</p>
<h2>Global Import</h2>
<p>JavaScript tem um recurso conhecido como <strong>implied globals</strong> (globals implícitas). Sempre que um nome é usado, o interpretador volta pela cadeia de escopo em busca de uma declaração de variável (<code>var</code>) para esse nome. Se nada for encontrado, a variável é assumida como global; se é usado em um assignmente, o global é criado se não existir. Isso significa que o uso ou a criação de variáveis ​​globais em um closure anônimo é fácil. Infelizmente, isso leva a código difícil de gerir, já que não é óbvio (para humanos) que as variáveis ​​são globais em um determinado arquivo.</p>
<p>Felizmente, o recurso de função anônima fornece uma alternativa fácil a isso. Ao passar globais como parâmetros para a função anônima, que os importa para o código. Eis um exemplo:</p>
<div class="wp_syntax">
<pre class="lang:js decode:true">(function ($, YAHOO) {
    // Agora se tem acesso às globais jQuery (como "$") e YAHOO nesse código
}(jQuery, YAHOO));</pre>
<p>&nbsp;</p>
</div>
<h2>Module Export</h2>
<p>Às vezes, você não quer apenas usar globais, mas quer declará-los. É possível fazer isso facilmente ao exportá-los, usando o valor de retorno da função anônima. Se o fizer, completará o Padrão de Módulo básico. Veja um exemplo completo:</p>
<div class="wp_syntax">
<pre class="lang:js decode:true">var MODULE = (function () {
    var my = {},
             privateVariable = 1;
 
    function privateMethod() {
        // ...
    }
 
    my.moduleProperty = 1;
    my.moduleMethod = function () {
        // ...
    };
 
    return my;
}());</pre>
</div>
<p>Observe que foi declarado um módulo global chamado <code>MODULE</code> com duas propriedades públicas: um método chamado <code>MODULE.moduleMethod</code> e uma variável chamada <code>MODULE.moduleProperty</code>. Além disso, ele mantém o estado interno privada usando o closure da função anônima — e também é possível importar globais necessários usando o padrão mostrado anteriormente.</p>
<p>&nbsp;</p>
<h2>Augmentation</h2>
<p>Uma limitação do Module Pattern até agora é que o módulo inteiro deve estar em um arquivo. Quem já trabalhou em uma grande base de código entende o valor de divisão de código em vários arquivos. Felizmente, existe uma boa solução: <strong>Augmentation</strong> (Ampliação). Em primeiro lugar, é preciso importar o módulo; então, são adicionadas novas propriedades e; por fim, ele é exportado.</p>
<p>Aqui está um exemplo de uso de Augmentation:</p>
<div class="wp_syntax">
<pre class="lang:js decode:true">var MODULE = (function (my) {
    my.anotherMethod = function () {
        // Método adicionado...
    };
    return my;
}(MODULE));</pre>
<p>É usada a palavra-chave <code>var</code> novamente para consistência, apesar de não ser estritamente necessário. Após este código ser executado, o módulo terá ganho um novo método público chamado <code>MODULE.anotherMethod</code>. Este arquivo “ampliado” também manterá seu próprio estado interno privado e importações.</p>
<p>&nbsp;</p>
</div>
<h2>Loose Augmentation</h2>
<p>Enquanto o exemplo acima requer a criação inicial do módulo em primeiro lugar e a ampliação acontecer depois disso, isso nem sempre é necessário. Uma das melhores coisas que um aplicativo JavaScript pode fazer em relação a desempenho é carregar scripts de forma assíncrona. É possível criar módulos flexíveis de várias partes que podem se carregar em qualquer ordem com o <strong>Loose Augmentation</strong> (Ampliação Fraca). Cada arquivo deve ter a seguinte estrutura:</p>
<div class="wp_syntax">
<pre class="lang:js decode:true">var MODULE = (function (my) {
    // Adiciona recursos...
    return my;
}(MODULE || {}));</pre>
</div>
<p>Neste padrão, a instrução <code>var</code> é sempre necessária. Note que a importação vai criar o módulo se ele ainda não existir. Isto significa que você pode usar uma ferramenta como <a href="http://labjs.com/">LABjs</a> e carregar todos os seus arquivos de módulo em paralelo, sem a necessidade de bloquear.</p>
<p>&nbsp;</p>
<h2>Tight Augmentation</h2>
<p><strong>Tight Augmentation</strong> (Ampliação Forte) é excelente, mas coloca algumas limitações no módulo, dentre as quais se destaca a impossibilidade de poder substituir as propriedades do módulo de maneira segura. Também não é possível usar as propriedades do módulo de outros arquivos durante a inicialização — embora seja possível em tempo de execução após a inicialização. Loose Augmentation implica numa ordem estabelecida de carregamento, mas permite substituições.</p>
<p>Eis um exemplo simples (ampliando o módulo-exemplo original):</p>
<div class="wp_syntax">
<pre class="lang:js decode:true">var MODULE = (function (my) {
    var old_moduleMethod = my.moduleMethod;
 
    my.moduleMethod = function () {
        // sobrescrita de método com acesso ao antigo através de old_moduleMethod foi 
    };
 
    return my;
}(MODULE));</pre>
<p><code>MODULE.moduleMethod</code> foi substituído, mas manteve uma referência para o método original, caso fosse necessário.</p>
<p>&nbsp;</p>
</div>
<h2>Cloning and Inheritance (Clonagem e Herança)</h2>
<p>Dentre os Padrões de Module Pattern, talvez este seja a opção mais flexível. Ele permite que algumas composições elegantes, mas que vem à custa da flexibilidade: propriedades que são objetos ou funções não serão duplicadas e existirão como um objeto com duas referências. Mudando uma, mudará a outra. Isso pode ser corrigido para objetos com um processo de clonagem recursiva, mas, provavelmente, não pode ser fixado para funções — exceto, talvez, com <code>eval()</code>.</p>
<pre class="lang:js decode:true">var MODULE_TWO = (function (old) {
    var my = {},
           key;
&amp;nbsp;
    for (key in old) {
        if (old.hasOwnProperty(key)) {
            my[key] = old[key];
        }
    }
&amp;nbsp;
    var super_moduleMethod = old.moduleMethod;
    my.moduleMethod = function () {
        // sobrescreve método ao clonar, acesso ao super através de super_moduleMethod
    };
&amp;nbsp;
    return my;
}(MODULE));</pre>
<p>&nbsp;</p>
<h2>Cross-File Private State (Estado Privado Entre-Arquivos)</h2>
<p>Uma limitação grave de dividir um módulo em vários arquivos é que cada arquivo mantém seu próprio estado privado e não tem acesso ao estado privado dos outros arquivos. Mas isso pode ser corrigido. Aqui está um exemplo de um módulo com Ampliação Fraca que vai manter o estado privado em todos as ampliações:</p>
<div class="wp_syntax">
<pre class="lang:js decode:true">var MODULE = (function (my) {
    var _private = my._private = my._private || {},
        _seal = my._seal = my._seal || function () {
            delete my._private;
            delete my._seal;
            delete my._unseal;
        },
        _unseal = my._unseal = my._unseal || function () {
            my._private = _private;
            my._seal = _seal;
            my._unseal = _unseal;
        };
 
        // Acesso permanente a _private, _seal e _unseal
 
        return my;
}(MODULE || {}));</pre>
</div>
<p>Qualquer arquivo pode definir propriedades em sua variável local <code>_private</code> e esta será imediatamente disponível para os outros. Uma vez que este módulo foi completamente carregado, o aplicativo deve chamar <code>MODULE._seal()</code>, que irá impedir o acesso externo ao interno <code>_private</code>.</p>
<p>Se este módulo fosse ampliado novamente, mais à frente na vida aplicativo um dos métodos internos, em qualquer arquivo, pode chamar <code>_unseal()</code> antes de carregar o novo arquivo e <code>_seal()</code> novamente depois de ter sido executado.</p>
<p>&nbsp;</p>
<h2>Submódulo</h2>
<p>O padrão de Module Pattern <strong>Submódulo</strong> (Sub-module) é considerado pela maioria como o mais simples. Há muitos bons casos para a criação de submódulos. É como criar módulos regulares:</p>
<div class="wp_syntax">
<pre class="lang:js decode:true ">MODULE.sub = (function () {
    var my = {};
    // ...
    return my;
}());</pre>
</div>
<p>Embora isso possa parecer bastante óbvio, vale a pena ser mencionado em um artigo desse tipo, haja vista que submódulos têm todas as capacidades avançadas de módulos normais, incluindo ampliação e estado privado.</p>
<p>&nbsp;</p>
<h2>Conclusão</h2>
<p>A maioria dos Padrões Avançados de Module Pattern podem ser combinados uns com os outros para criar padrões mais úteis. Não raramente é possível encontrar, em aplicações mais complexas, a combinação de Ampliação Fraca, Estado Privado e Submódulos.</p>
<p>No decorrer do artigo, não se mencionou a respeito de performance, mas uma nota rápida sobre isso seria: Module Pattern é bom para performance! Ele passa por minificação muito bem, o que faz com que o download seja mais rápido. Usar Loose Augmentation permite downloads paralelos, fáceis e sem bloqueios. O tempo de inicialização é, provavelmente, um pouco mais lento do que outros métodos, mas o custo-benefício vale a pena. Desempenho em tempo de execução não deve sofrer penalidades desde que globais sejam importados corretamente e, provavelmente, há aumento de velocidade em submódulos, encurtando a cadeia de referência com variáveis ​​locais.</p>
<p>Para fechar sobre Module Patterns, aqui está um exemplo de um submódulo que se carrega dinamicamente a seu parent (criando-se se ele não existe) — o estado privado foi deixado de fora para que o exemplo fique mais conciso, mas incluir isso seria simples.</p>
<div class="wp_syntax">
<pre class="lang:js decode:true ">var UTIL = (function (parent, $) {
    var my = parent.ajax = parent.ajax || {};
 
    my.get = function (url, params, callback) {
        // Um pouquinho de trapaça... xD
        return $.getJSON(url, params, callback);
    };
 
    // etc
 
    return parent;
}(UTIL || {}, jQuery));</pre>
<p>Este padrão de código permite que toda uma base de códigos complexa hierárquica seja completamente carregada em paralelo, com sub-módulos e tudo o mais.</p>
</div>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
