{"componentChunkName":"component---src-templates-blog-post-js","path":"/factory-strategy/","result":{"data":{"markdownRemark":{"html":"

Introdução Design Patterns

\n

Padrões de projeto são formas mais padronizadas para solucionar problemas em comum…\n\"confuso\"

\n

Ok tentando ser mais claro; quando precisamos organizar o nosso código, deixá-lo flexível às mudanças, adaptável e reutilizável podemos seguir dois caminhos:

\n\n

Pensando assim nasceram os padrões de projeto (Design Patterns).\nA idéia de padrões de projetos não é nova (anos 70), já que na maioria das vezes os problemas são muito parecidos, mas em 1995 é que essa ideia se tornou mais tangível com o livro Design Patterns: Elements of Reusable Object-Oriented Software (Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos) onde eram catálogados e descritos.\nForam divididos em três grupos de padrões:

\n\n

Com isso foram catálogados 23 padrões que ficaram conhecidos como padrões GoF, Gang of Four, uma referência aos criadores do livro, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides.

\n

Projeto prático

\n

Vamos fazer um projeto prático, a intenção aqui não será abordar todos os padrões mas sim como podemos analisar um problema e definir qual padrão poderia ser usado.

\n

Problema

\n

Vamos pensar que temos uma aplicação que recebe o nome de uma cerveja e a partir disso deve executar algo para cada tipo de cerveja. Como poderíamos resolver isso? Acho que a solução de primeira e mais simples poderia ser um if/else assim:

\n
if(cerveja.getName() == \"IPA\"){\n    //faça algo\n}else {\n    //faça outra coisa\n}
\n

Essa implementação parece ser razoável a primeira vista mas aqui temos um problema que pode ser considerado, e se amanhã surgir outro tipo de cerveja? Ou se eu tiver um catálogo com mais de 100 tipos de cervejas? Vou colocar mais um if ou então vou substituir por um block switch case? As duas abordagens na verdade mascaram o mesmo problema que é o problema de sua implementação poder crescer infinitamente. Isso gera um código gigante, difícil de dar manutenção e difícil de entender e ainda mais existe um princípio que esse tipo de implementação fere que é o princípio Open/Close (Aberto/Fechado) do S.O.L.I.D. que diz: “entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação”.\nTrocando em miúdos isso quer dizer que você ter várias extensões de uma interface, classe e etc. sem mudar nada neles. Mas como trazer isso pro nosso caso?

\n

Strategy

\n

Aqui veremos o primeiro padrão de projeto que pode resolver essa situação. O padrão Strategy é um padrão comportamental, isso quer dizer que usando ele você pode definir comportamentos diferentes dependendo do que for passado, isso casa bem com o esse problema mas como implementar?\nA primeira coisa que vamos fazer é criar uma interface que represente pra nós a nossa ação, vou criar com o nome Beer:

\n
package com.example.demo.beer;\n\npublic interface Beer {\n\t\n\tvoid drink();\n\t\n\tString label();\n\n}
\n

Então aqui temos o contrato (interface) do que eu quero que toda cerveja tenha, quero que ela tenha a ação de drink e que ela tenha um rótulo label, essa parte da label vai ficar mais claro daqui a pouco.\nE agora eu vou implementar as nossa cervejas vou criar três tipos aqui, IPA, ALE e STOUT todas vão seguir esse mesmo exemplo:

\n
public class Ale implements Beer{\n\n\t@Override\n\tpublic void drink() {\n\t\tSystem.out.println(\"Drink a ale beer\");\n\t}\n\n\t@Override\n\tpublic String label() {\n\t\treturn \"Ale\";\n\t}\n\n}
\n

Com isso se eu já instânciar qualquer cerveja ele já vai ser capaz de chamar a implementação correta mais ou menos assim:

\n
public class Test {\n\n    public void callCorrectBeer(){\n        Beer beer = new Ale();\n        beer.drink();\n    }\n}
\n

Isso já ajuda bastante por que imaginando que eu tenho um dado de entrada para a minha aplicação eu poderia fazer algo assim:

\n
public class Main {\n\n    public static void main(String... args){\n        //dado de entrada\n        String beerAle = \"Ale\";\n        \n        Beer beer = //de alguma forma eu descobrir que se trata de uma Ale\n        beer.drink();\n    }\n}
\n

Se eu mudar o tipo pra STOUT por exemplo o que mudaria é comportamento mas fica transparente pra quem está chamando.

\n

Factory

\n

Precisamos agora ter um jeito de saber qual é a cerveja que eu quero criar para chamar a nossa Strategy certa. Um jeito é tendo uma classe que tenha como especialidade criar instâncias de Beer corretas, é um factory (fábrica) que irá se preocupar em criar as instâncias corretas pra nós.\nEsse padrão entra como sendo um padrão criacional, a única preocupação dele é criar objetos de forma correta pra gente, vamos fazer com que seja o mais genérico possível, então antes vamos criar uma interface que vai ser responsável por criar objetos pra gente se baseando no tipo que vamos passar pra ele:

\n
package com.example.demo.beer.factory;\n\npublic interface AbstractFactory<T> {\n\t\n\tT create(String type);\n\n}
\n

Aqui usamos o recurso de Generics do Java pra deixar o mais genérico possível, então a nossa interface receberá o tipo terá o método create que devolve pra gente esse tipo definido.\nE agora vamos fazer a implementação dessa factory:

\n
public class FactoryBeer implements AbstractFactory<Beer> {\n\t\n\t@Override\n\tpublic Beer create(String type) {\n\n        if(type == \"Ale\"){\n            return new Ale();\n        }if else(type == \"Stout\"){\n            return new Stout();\n        }else {\n            return Ipa();\n        }\n\t}\n}
\n

Aqui pode parecer que demos uma grande volta pra cair num if/else de novo mas na verdade estamos deixando em um único ponto, que é na nossa classe especializada em fabricar objetos, mas podemos melhorar isso, nesse projeto eu uso Spring Boot e ele trabalha com o conceito de IoC (Inversão de Controle) e nos fornece uma interface que é a ApplicationContext que gerencia os nossos Beans, pra não entrar muito dentro dos detalhes a grosso modo tudo o que usar as annotations @Bean, @Component, @Controller, @Service, @Repository, @Autowired, e @Qualifier serão objetos que o Spring vai gerenciar e ele é que vai decidir quando eles estarão disponíveis pra uso. Então depois de toda essa explicação é pra dizer que podemos então delegar essa responsabilidade pro ApplicationContext pra gente assim:

\n
@Component\npublic class FactoryBeer implements AbstractFactory<Beer> {\n\t\n\t@Autowired\n\tprivate ApplicationContext context;\n\n\t@Override\n\tpublic Beer create(String type) {\n\t\t\n\t\treturn context.getBean(type);\n\t}\n\n}
\n

O que muda aqui é que adicionamos a anotação @Component e isso faz com que automaticamente o Spring comece a gerenciar a injeção das nossas dependências, injetamos com a anotação @Autowired a nossa interface ApplicationContext e no nosso método chamamos o getBean e ele vai trazer pra gente a instância certa. Só tem um problema aqui, caso seja passada uma String type errada que não exista ele vai lançar uma BeansException, inclusive o próprio método getBean faz parte da API da interface BeanFactory que é fábrica de Beans do Spring.\nVamos então criar um jeito onde eu passe um tipo que existe e ele irá chamar o tipo existente, vamos criar uma enumeração Enum onde conseguimos registrar as nossas classes de serviço e um método de busca:

\n
public enum BeerType {\n\t\n\tALE(\"Ale\", Ale.class),\n\tIPA(\"Ipa\", Ipa.class),\n\tSTOUT(\"Stout\", Stout.class);\n\t\n\tprivate String name;\n\tprivate Class<? extends Beer> type;\n\t\n\tBeerType(String name, Class<? extends Beer> type){\n\t\tthis.name = name;\n\t\tthis.type = type;\n\t}\n\t\n    public static BeerType of(String value) {\n\n        return Arrays.stream(values()).filter(type -> type.name.equalsIgnoreCase(value)).findFirst().get();\n    }\n\t\n\tpublic String getName() {\n\t\treturn name;\n\t}\n\t\n\tpublic Class<? extends Beer> getType(){\n\t\treturn type;\n\t}\n\n}
\n

Um ponto muito importante é que as nossas três classes de serviço devem ser anotadas com algumas das anotações citadas anteriormente para gerenciamento do Spring, no caso iremos anotar com @Component para ficar mais semântico.\nEntão o resultado final da nossa factory ficaria assim:

\n
@Component\npublic class FactoryBeer implements AbstractFactory<Beer> {\n\t\n\t@Autowired\n\tprivate ApplicationContext context;\n\n\t@Override\n\tpublic Beer create(String type) {\n\t\t\n\t\treturn context.getBean(BeerType.of(type).getType());\n\t}\n\n}
\n

Service

\n

Agora vamos criar a classe que vai amarrar tudo pra gente:

\n
@Service\npublic class BeerService {\n\t\n\t@Autowired\n\tprivate AbstractFactory<Beer> factory;\n\t\n\tpublic void process(String beer) {\n\t\tBeer beerBean = factory.create(beer);\n\t\tbeerBean.drink();\n\t}\n\n}
\n

Ela é só a chamada dos serviços, injetamos a nossa factory do tipo Beer e chamamos o seu create passando o tipo como parâmetro e depois chamamos o método drink.

\n

Rodando a aplicação

\n

Rodando a nossa aplicação na nossa main:

\n
@SpringBootApplication\npublic class DemoApplication implements CommandLineRunner{\n\t\n\t@Autowired\n\tprivate BeerService service;\n\n\tpublic static void main(String[] args) {\n\t\tSpringApplication.run(DemoApplication.class, args);\n\t}\n\n\t@Override\n\tpublic void run(String... args) throws Exception {\n\t\t\n\t\tservice.process(BeerType.ALE.getName());\n\t\tservice.process(BeerType.IPA.getName());\n\t\tservice.process(BeerType.STOUT.getName());\n\t}\n\n}
\n

Temos a saída:

\n
Drink a ale beer\nDrink a ipa beer\nDrink a stout beer
\n

Finalizando

\n

A decisão de usar design patterns e quais usar não é uma escolha tão fácil, leva tempo pra saber qual é o melhor caso e como combinar padrões, como por exemplo nesse projeto não foi usado explícitamente nenhum padrão estrutural mas a finalidade dos design patterns é facilitar e padronizar os nossos códigos pensando em reutilização, refatoração, manutenção e flexibilidade.\nVimos aqui alguns padrões que podem ser usados, como pôde ser visto nós temos um maior custo de desenvolvimento para criar o código da nossa aplicação porém o custo ao longo do tempo compensa pois nesse código temos maior flexibilidade caso surja uma regra nova ou precisarmos trocar alguma implementação do que já existe, então temos um código reutilizável, com menor custo de manutenção e como estamos usando um padrão de mercado caso algum dia outro desenvolvedor ou equipe precise dar suporte ou fazer alguma coisa nova não perderá tanto tempo se eles souberem os padrões ficará mais fácil o entendimento do código.\nAqui temos o GitHub do projeto.

","fields":{"slug":"/factory-strategy/"},"frontmatter":{"date":"14 de setembro de 2020","description":"Como utilizar Design Patterns em uma aplicação Java","title":"Usando padrões de projeto em uma aplicação","tags":["Desenvolvimento","Java","Design Patterns"],"author":"Guilherme Alves","image":{"id":"bba649ce-6ffe-59a5-9d63-b4818e862392","publicURL":"/static/d006b6950f02f08003c124d36aa491a9/design-patterns.png","childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAMCAIAAADtbgqsAAAACXBIWXMAAAsSAAALEgHS3X78AAABr0lEQVQoz42SXU/iQBSG+dteeeON3ngjGz8SskpYNOICoqioMUbxEwE1bXClRmqBohWHlrbT6cycnRZcdWOiJycnkzPzvDPnzUTgfXAuCjOtweLLiPxHctvGxRP4XkQ+kIQ4qQwulTmlr/0v4SHp92ML/XgSn5e57394kdASyRgPK7xKhzDjDMC9kqz4ohmdJbdK0KNMSPpak/V6Q4lBfj6z5/HbuhdPekupAMNE9Ozl33j/QLjgnV9QrenX/nilCt4/ZOHTIgOtomKcqS+GTdqN9mNdFTt7Nf3BBbq27mztWjMxc3zSmpru/0y4B8doZJQ9d0M4vLWq9eZPG3mpk5E620oXE5quNlWH03QWjU2Yk1Hv8Ngcm3C3dvo/5sRoQ/ifozlJj52o86dqXtaxTy0ceGNvFBjqMccRZwK3OGcYM0LeZq5oqKohxbATF1qipMm6SShDtheIrhcgmYHsJuQKsHcEiRT8SgeLlTV4aAdwWUOr1+0NWV+5bC1Xmtmr1qasF5WnQP/uHqoSFM/gqARGF+QbuJRBaUCtDsbLm9vIIbrptpDb6NodC3/ng/4FewSbJFO/orgAAAAASUVORK5CYII=","aspectRatio":1.6842105263157894,"src":"/static/d006b6950f02f08003c124d36aa491a9/c04dc/design-patterns.png","srcSet":"/static/d006b6950f02f08003c124d36aa491a9/c67b7/design-patterns.png 320w,\n/static/d006b6950f02f08003c124d36aa491a9/c04dc/design-patterns.png 373w","sizes":"(max-width: 373px) 100vw, 373px"}}}},"timeToRead":7}},"pageContext":{"slug":"/factory-strategy/","previous":{"fields":{"slug":"/spring-feign-assincrono/"},"frontmatter":{"title":"Comunicação assíncrona com Feign","date":"08 set, 2020"}},"next":{"fields":{"slug":"/go-design-patterns/"},"frontmatter":{"title":"Padrões de projeto com GO","date":"18 set, 2020"}}}},"staticQueryHashes":["63159454"]}