Patterns de criação na vida real

Filipe Nunes
3 min readJan 4, 2020

--

Photo by Alice Achterhof on Unsplash

Bem, agora que sabemos a origem, oque é e do que se alimenta estes tais de Designs Patterns, vamos começar a codar e entender eles, e deixar de apenas cuspir códigos no Android Studio. Caso não esteja entendo nada, pode iniciar no artigo anterior.

Pattern de criação, eles lidam com mecanismos de criação de objetos, como o nome já deixa implícito, ele tenta criar objetos de maneiras adequadas para cada situação. Criar objetos de qualquer forma, pode ter sérios problemas no futuro, adicionado uma complexidade desnecessária. E por este motivo foi criado os patterns abaixo.

AbstractFactory

O problema que este padrão tenta resolver é da instanciação na existência de uma família de produtos ou classes. O exemplo dado é o seguinte: você tem jargões de raças(RaceSpeak), como Elf, Dwarf. Essas raças tem diferentes implementações.

Nesse caso, a solução consiste em duas partes:

  • Crie interfaces padrões para as raças, neste caso apenas RaceSpeak. E todo o seu sistema vai trabalhar apenas com essas interfaces que você definiu.
  • Defina uma Abstract Factory, que tem os métodos de instanciação para cada uma dessas interfaces padrões definidas acima

E testamos desta forma

Podemos aplicar onde uma família de produtos ou classes precisa ser instanciado, sem dependência de suas classes concretas.

FactoryMethod

De forma geral todos os padrões Factory (Simple Factory, Factory Method, Abstract Factory) encapsulam a criação de objetos. O padrão Factory Method por sua vez encapsula a criação de objetos, com uma pequena diferença, é que neste padrão encapsula-se a criação de objetos deixando as subclasses decidirem quais objetos criar.

Como construir a solução:

  • Crie Sealed Class para as casas. E então vamos usar ele como uma interface.
  • Crie seus objetos, eles podem ser do tipo object, class e data class, utilizando nossa Sealed Class.
  • Agora criaremos nosso objeto que será encapsulado, neste caso é o name.
  • Defina uma Factory Method, que tem os métodos de instanciação para cada uma dessas interfaces padrões definidas acima

E testamos desta forma

O mesmo facilita bastante quando trabalhamos com aplicações que devem instanciar objetos, onde temos especializações de suas instanciações, mas trabalhamos com um retorno comum entre essas especializações.

Singleton

A idéia do cerce da questão quando falamos em Singleton, é de que tenhamos uma classe/objeto capaz de ser instanciada uma ÚNICA VEZ e com visibilidade e acessibilidade global dessa instância em um determinado escopo de projeto.

Este padrão em Kotlin, é o mais simples de criarmos, pois precisamos apenas utilizar o prefixo object antes do nome da nossa classe, como fizemos na Boss.

E testamos desta forma

Em suma, este padrão é utilizado quando necessita-se de um ponto único para criação de uma instância de classe e quando precisamos de apenas uma instância de uma classe. Mas tome cuidado, pois lembre que ela fica instanciada durante toda a aplicação, e desta forma consumindo memória.

Builder

Frequentemente utilizado quando precisamos criar um objeto complexo e também é adequado quando se trata da construção de representações múltiplas de uma mesma classe.

Tenha em mente que, quanto mais complexa for uma aplicação, maiores serão as complexidades existentes nas classes e objetos criados. Objetos complexos passam a ser construídos a partir de peças geradas a partir de outros objetos, o que demanda uma necessidade maior em relação a sua construção, um cuidado especial poderíamos dizer.

Utilizado para construção de objetos complexos fazendo-se uso de uma abordagem de desenvolvimento passo a passo. Vamos usar como exemplo a criação de um AlertDialog (que é um Builder). Basicamente podemos dividir em 4 componentes.

  • Classe Builder, nossa classe Dialog, com os passos que serão gerados.
  • Concrete Builder, nossa classe DialogBuilder, que é responsável pela construção e implementação.
  • Director, nossa função dialog este cara vai gerar o objeto final
  • Product, esta na função de teste como podemos ver

Ele é uma ótima abordagem, não apenas para as classes de modelo, mas para todos os objetos que possuem mais de três ou quatro parâmetros. Com um pouco de trabalho adicional, podemos aumentar a legibilidade do nosso código.

Bem chegamos ao final dos patterns de criação, no próximo artigo vamos ver os mais utilizados de estrutura.

Para ajudar em seus estudos podem utilizar o projeto com todos os patterns que falamos aqui.

--

--

Filipe Nunes

Fanatic in love with technology. Software Engenier / Specialist Mobile