O Object Literal Pattern é provavelmente o jeito mais simples encapsular as partes de uma implementação de baixo de um objeto de guarda-chuva que funciona como um Módulo. O nome deste padrão descreve como é utilizado. O desenvolvedor apenas precisa declarar uma variável e nomear um objeto que irá relacionar com todas as partes que forem necessárias encapsuladas dentro deste Módulo.
Vamos criar um Módulo que fornece um único inteiro para uma página, é similar ao que o jquery.guid faz:
var simpleguid = {
guid: 1,
init: function(){
this.guid = 1;
},
increaseCounter: function(){
this.guid++;
//ou simpleguid.guid++;
},
getNext: function(){
var nextGuid = this.guid;
this.increaseCounter();
return nextGuid;
}
}
Uma simples regra que você pode seguir deste padrão é definir todas as variáveis e funções que cada implementação precisa como as propriedades de um objeto. Nosso código é reutilizável e não polui o Global Namespace, outros podem apenas definir uma simples variável para o nosso Módulo, é o simpleguid neste caso.
Podemos acessar as propriedades internas do Módulo, ou utilizar a keyword this, como a this.guid, ou utilizar o nome completo do Módulo simple.guid. Para utilizar o Módulo do código apresentado, precisamos acessar sua propriedade utilizando o seu nome. Por exemplo, chamando o método simpleguid.getNext() que retornará o próximo número e mudará o estado do Módulo incrementando o seu contador interno.
Um ponto negativo deste padrão é que não fornece nenhuma segurança interna do Módulo. Todas as partes internas do Módulo podem ser acessadas e subscritas por um código externo, apesar que somos nós que escolhermos o que será exposto, como os métodos simpleguid.init() e o simpleguid.next(). Há muitas convenções de como escolher os nomes, pela sua funcionalidade ou adicionando o underscore(_) para os nomes das propriedades que serão utilizadas apenas internamente, mas tecnicamente isto não resolve o ponto negativo.
Outra desvantagem é escrever um Módulo gigante utilizando um objeto literal. É verdade que desenvolvedores JavaScript estão acostumados a terminar suas variáveis com ponto e vírgula(;), e escrevem grandes Módulos utilizando vírgula(,) depois de cada propriedade, que facilmente pode levar a erros de sintaxe.
Apesar deste padrão torna fácil a declaração de Namespaces aninhados para um Módulo, pode acontecer de a estrutura ficar com uma legibilidade ruim, neste caso há a necessidade de criar vários níveis. Vamos ver um exemplo:
var myTodoApp = {
todos: [],
addTodo: function(todo) { this.todos.push(todo); },
getTodos: function() { return this.todos; },
updateTodo: function(todo) { /*…*/ },
imports: {
fromGDrive: function() { /*…*/ },
fromUrl: function() { /*…*/ },
fromText: function() { /*…*/ }
},
exports: {
gDrivePublicKey: ‘#wnanqAASnsmkkw’,
toGDrive: function() { /*…*/ },
toFile: function() { /*…*/ }
},
share: {
toTwitter: function(todo) { /*…*/ }
}
};
Felizmente neste caso pode ser facilmente ajustado, separando o objeto literal em múltiplas assinaturas de submódulos (preferencialmente em arquivos separados):
var myTodoApp = {
todos: [],
addTodo: function(todo) { this.todos.push(todo); },
getTodos: function() { return this.todos; },
updateTodo: function(todo) { /*…*/ }
};
/*…*/
myTodoApp.exports = {
gDrivePublicKey: ‘#wnanqAASnsmkkw’,
toGDrive: function() { /*…*/ },
toFile: function() { /*…*/ }
};
/*…*/
😍 Aulas de Javascript – http://bit.ly/blackzigjavascript
jQuery Design Patterns (English Edition) – https://amzn.to/2RJaILW
#designpattern #objectliteralpattern
Deixe um comentário