Padrões de design no desenvolvimento moderno de JavaScript

O autor do material, cuja tradução publicamos, diz que, no mundo do desenvolvimento de software, “design arquitetônico” pode ser chamado de processo de construção de um aplicativo, durante o qual eles se esforçam para torná-lo de alta qualidade, confiável e bem acessível. Além disso, os padrões de design (padrões) permitem operar com conceitos que são abordagens para resolver problemas comuns. Essas decisões podem variar de abstratas, conceituais a muito específicas. Seu conhecimento permite que os desenvolvedores se comuniquem efetivamente entre si.

Se pelo menos dois desenvolvedores de uma equipe entendem padrões, falar sobre a solução de problemas enfrentados pela equipe se torna muito produtivo. Se apenas um membro da equipe conhece os padrões, isso geralmente esclarece o que ele sabe dos outros membros da equipe.



O objetivo deste artigo é interessar aos leitores uma espécie de apresentação formal de conhecimento no campo do desenvolvimento de software, mostrando a idéia de padrões de design e descrevendo vários padrões que são interessantes, pois encontram aplicação no desenvolvimento moderno do JavaScript.

Padrão Singleton

▍ Geral

O padrão de design “singleton” (também chamado de “singleton”) não pode ser chamado de um dos padrões mais usados, mas iniciamos a conversa com ele, pois é relativamente fácil de entender.

Esse padrão cresce a partir do conceito matemático de um singleton - um conjunto de singleton, ou seja, um conjunto contendo apenas um elemento. Por exemplo, o conjunto {null} é um singleton.

No campo do desenvolvimento de software, o significado do padrão "singleton" se resume ao fato de limitarmos o número de instâncias possíveis de uma determinada classe a um objeto. Na primeira tentativa de criar um objeto com base em uma classe que implementa esse padrão, esse objeto é realmente criado. Todas as tentativas subseqüentes de criar uma instância da classe retornarão o objeto criado durante a primeira tentativa de obter uma instância da classe.


Por que outro super-herói quando temos Batman?

Acima está um exemplo de uma classe que implementa o padrão singleton.

▍ Por que é necessário?

É claro que esse padrão nos permite limitar-nos a apenas um "super-herói" (este é obviamente o Batman). Mas por que mais ele poderia precisar?

Embora esse padrão não tenha seus próprios problemas (anteriormente chamado de mal, dado o singleton chamado de mentiroso patológico ), em algumas situações pode ser muito útil. Uma dessas situações é inicializar objetos de configuração. Em um aplicativo típico, faz sentido manter apenas uma instância desse objeto, a menos que, de acordo com os recursos do projeto, vários objetos semelhantes sejam usados ​​nele.

▍Onde usá-lo?

O principal exemplo de uso do padrão singleton em grandes estruturas populares são os serviços Angular. A documentação do Angular possui uma página separada explicando como tornar um serviço um singleton.

O design de serviços na forma de singletones tem um significado profundo, pois os serviços são usados ​​como repositórios de estado, configuração e permitem organizar a interação entre componentes. Tudo isso leva ao fato de que o desenvolvedor precisa para que seu aplicativo não tenha várias instâncias do mesmo serviço.

Considere um exemplo. Suponha que tenhamos um aplicativo simples usado para contar o número de cliques nos botões.


Cada clique em qualquer um dos botões atualiza o contador

O número de cliques nos botões deve ser armazenado em um objeto, o que implementa os seguintes recursos:

• Permite contar cliques nos botões.
• Permite ler o valor atual do contador de cliques.

Se esse objeto não fosse um singleton (e cada botão tivesse sua própria instância associada a esse objeto), o programa calcularia incorretamente o número de cliques nos botões. Além disso, com essa abordagem, é necessário resolver o seguinte problema: "De qual objeto específico responsável pela contagem dos cliques serão retirados os dados exibidos na tela?"

Padrão do observador

▍ Geral

Um padrão de observador é um padrão de design no qual um objeto chamado sujeito mantém uma lista de objetos dependentes chamados de observador e os notifica automaticamente quando seu estado muda, geralmente chamando um de seus métodos .

Não é difícil entender esse padrão se você encontrar sua analogia no mundo real. Ou seja, estamos falando de assinaturas de jornais.

Suponha que você normalmente compre jornais em um quiosque. Você vai lá, perguntando se há uma nova edição do seu jornal favorito. Se o que você precisa não está no quiosque, você volta para casa, perdendo tempo e depois volta ao quiosque. Se considerarmos essa situação aplicada ao JavaScript, seria como uma pesquisa cíclica de alguma entidade, realizada até que os dados necessários sejam recebidos dela.

Depois, quando você finalmente conseguir o jornal de que precisa, poderá começar o que se esforça por todo esse tempo - tome uma xícara de café e desdobre o jornal. Em JavaScript, isso equivale a chamar um retorno de chamada, que íamos chamar após obter o resultado desejado.


Finalmente você pode ler o jornal

Seria muito mais razoável fazer isso: assine um jornal e receba sua última edição todos os dias. Com essa abordagem, o editor informará que uma nova edição do jornal foi lançada e a entregará a você. Você não precisa mais ir ao quiosque. Não há mais perda de tempo.

Se você alternar para o JavaScript novamente, isso significa que você não precisa mais esperar no loop por algum resultado e, após recebê-lo, chamar uma determinada função. Em vez disso, você informa ao assunto que está interessado em determinados eventos (mensagens) e passa a função de retorno de chamada para ele, que deve ser chamada quando os dados de interesse estiverem prontos. Você, nesse caso, se torna um observador.


Agora você nunca mais perderá o seu jornal favorito da manhã

O padrão em questão tem um bom recurso: você não precisa ser o único observador. Se você não conseguir o seu jornal favorito, ele ficará chateado. Mas o mesmo acontecerá com outras pessoas que não podem comprá-lo. É por isso que vários observadores podem se inscrever em um assunto.

▍ Por que é necessário?

O padrão "observador" é usado em muitas situações, mas geralmente deve ser usado quando você deseja criar um relacionamento um para muitos entre objetos e, ao mesmo tempo, esses objetos não devem estar fortemente conectados. Além disso, o sistema deve poder notificar um número ilimitado de objetos sobre determinadas alterações.

Os aplicativos JavaScript são um ótimo lugar para aplicar o padrão de observador, já que tudo é orientado a eventos aqui e, em vez de se referir constantemente a uma determinada entidade para descobrir se ocorreu um evento de seu interesse, será muito melhor deixá-lo notificá-lo quando a ocorrência deste evento (é semelhante ao antigo ditado: "Não ligue para nós. Quando necessário, nós ligaremos para você").

É provável que você já tenha usado desenhos que se assemelhem ao padrão de observador. Por exemplo, este é addEventListener . A adição de um ouvinte de evento a um elemento possui todos os sinais de uso do padrão observador:

• Você pode se inscrever no objeto.
• Você pode cancelar a inscrição no objeto.
• Um objeto pode informar todos os seus assinantes sobre o evento.

É útil saber sobre a existência do padrão "observador" no sentido de que esse conhecimento permite que você realize seu próprio assunto, ou muito mais rápido do que antes, para descobrir uma solução existente usando esse padrão.

▍Onde usá-lo?

A implementação básica desse padrão não precisa ser particularmente complicada, mas existem excelentes bibliotecas que o implementam e são usadas em muitos projetos. Estamos falando do projeto ReactiveX e de sua versão JavaScript do RxJS .

A biblioteca RxJS permite não apenas se inscrever em assuntos, mas também oferece ao programador a capacidade de transformar dados de várias maneiras, permite combinar muitas assinaturas, melhora a capacidade de gerenciar operações assíncronas. Além disso, suas capacidades não se limitam a isso. Se você quiser aumentar os recursos de seus programas para processar e converter dados para um nível superior, poderá recomendar o estudo da biblioteca RxJS.

Além do padrão "observador", o projeto ReactiveX pode se orgulhar da implementação do padrão "iterador", que permite ao sujeito informar os assinantes sobre a conclusão da assinatura, em essência, permitindo cancelar a assinatura por iniciativa do sujeito. Neste artigo, não vou falar sobre o padrão "iterador", mas posso dizer que, se você está apenas começando a aprender padrões de design, estudar esse padrão e pensar em como ele se compõe com o padrão "observador" pode ser um bom exercício.

Padrão de fachada

▍ Geral

O padrão da fachada recebeu esse nome da arquitetura. Na arquitetura, uma fachada é geralmente um dos lados externos de um edifício, geralmente o lado da frente. O inglês emprestou a palavra "fachada" do francês. Estamos falando da palavra "fachada", que, entre outras coisas, se traduz como "a frente do edifício".

A fachada do edifício em arquitetura é o exterior do edifício, escondendo o que está dentro. Propriedades semelhantes podem ser observadas no padrão de “fachada”, uma vez que visa ocultar mecanismos internos complexos atrás de uma determinada interface externa. Sua aplicação permite que o desenvolvedor trabalhe com uma API externa, organizada de maneira simples e, ao mesmo tempo, fornece a capacidade de alterar os mecanismos internos ocultos atrás da fachada, sem prejudicar o desempenho do sistema.

▍ Por que é necessário?

O padrão de "fachada" pode ser usado em um grande número de situações, entre as quais podemos observar especialmente quando eles tentam facilitar o entendimento do código (isto é, ocultam mecanismos complexos por trás de APIs simples) e quando fragmentos de sistemas tendem a criar o máximo possível mais frouxos conectados um ao outro.


Esses objetos precisam de algo da cova do dragão.

É fácil ver que um objeto de fachada (ou uma camada com vários objetos) é uma abstração muito útil. É improvável que alguém queira se deparar com um dragão se isso puder ser evitado. O objeto de fachada é necessário para fornecer a outros objetos uma API conveniente, e esse objeto lidará com todos os truques de dragão por conta própria.

Outra característica útil do padrão de "fachada" é que o dragão pode ser "refeito" conforme desejado, mas isso não afetará outras partes do aplicativo. Suponha que você queira substituir um dragão por um gatinho. O gatinho, como o dragão, tem garras, mas é mais fácil alimentar. Mude o dragão para um gatinho - isto significa - para reescrever o código do objeto de fachada sem fazer alterações nos objetos dependentes.

▍Onde usá-lo?

O padrão da fachada é frequentemente encontrado em Angular. Lá, os serviços são usados ​​como um meio de simplificar alguma lógica básica. Mas esse padrão é aplicável não apenas em Angular; abaixo, você pode ver isso.

Suponha que precisamos adicionar um sistema de gerenciamento de estado ao aplicativo. Para resolver esse problema, você pode usar várias ferramentas, entre elas - Redux, NgRx, Akita, MobX, Apollo, além de - novas ferramentas constantemente emergentes. Por que não experimentar todos eles?
Qual é a principal funcionalidade que uma biblioteca de gerenciamento de estado deve fornecer? Esses são provavelmente os seguintes recursos:

• Um mecanismo para notificar o sistema de gerenciamento de estado de que precisamos mudar de estado.
• O mecanismo para obter o estado atual ou seu fragmento.

Tudo não parece tão ruim.

Agora, armado com o padrão de “fachada”, você pode escrever fachadas para trabalhar com várias partes do estado, fornecendo APIs convenientes que podem ser usadas no programa. Por exemplo, algo como facade.startSpinner() , facade.stopSpinner() e facade.getSpinnerState() . Esses métodos são fáceis de entender, você pode consultá-los facilmente em uma conversa sobre o programa.

Depois disso, você pode trabalhar com objetos que implementam o padrão de “fachada” e escrever código que transformará seu código para que ele possa trabalhar com o Apollo (gerenciar o estado com o GraphQL é um tópico importante). Talvez durante os testes você descubra que o Apollo não é adequado para você ou que você se sente desconfortável ao escrever testes de unidade com base nesse sistema de gerenciamento de estado. Não tem problema - escreva uma nova fachada projetada para oferecer suporte ao MobX e tente o sistema novamente.


Diferentes sistemas para gerenciar o estado da aplicação, acessados ​​através de uma única fachada, também podem ser dragões ...

Sumário

Você provavelmente percebeu que, quando falamos sobre padrões de design, não consideramos exemplos de código. O fato é que uma análise profunda de cada padrão desenha pelo menos um capítulo separado, longe do livro mais fino. A propósito, como estamos falando de livros, aqui temos publicações interessantes que você pode ver para aqueles que desejam se aprofundar no estudo de padrões.

No final, quero dizer que, no desenvolvimento de padrões, nada supera uma pesquisa na Internet, lendo e testando independentemente várias idéias. Mesmo que você nunca use padrões, entenderá algo novo, aprenderá sobre eles e crescerá em áreas inesperadas para você.

Caros leitores! Quais padrões de design você usa?