Qual seu Estado ? Cidade:

CIDADE - ESTADO

Arquitetura E Desenvolvimento De Software Andndash Parte 02 Abstract Factory


Fonte: imasters.com.br/desenvolvimento/arquitetura-e-desenvolvimento-de-software-parte-02-abstract-factory

Arquitetura e desenvolvimento de software – Parte 02: Abstract Factory | iMasterswe are developersEm desenvolvimentoclose-circleDigite sua palavra-chaveEm desenvolvimentoPowered by:Desenvolvimento6 dez, 2018Arquitetura e desenvolvimento de software – Parte 02: Abstract Factory449 visualizações COMPARTILHE!Gustavo Bellini BigardiTem 12 artigos publicados com 4924 visualizações desde 2018PublicidadeGustavo Bellini Bigardi12editDesenvolvedor e arquiteto de software a mais de 12 anos, trabalhando tecnologias como .NET, Java, Go, NodeJS e outras. Palestrante em eventos da comunidade, com foco em tecnologias da Microsoft, Certificações MCSA Web e MCSD App Builder (Microsoft) e baterista nas horas vagas.Leia mais14 dez, 2018Arquitetura e desenvolvimento de software – Parte 04: Builder10 dez, 2018Arquitetura e desenvolvimento de software – Parte 03: Factory Method29 nov, 2018Windows Forms, WPF: ainda vale a pena?E ai, pessoal! Tudo certo? Na primeira parte do artigo fizemos uma reflexão do papel do arquiteto de software no time e como arquitetura de software deve ser algo de interesse de todos para que não exista alguém centralizado de onde tudo depende. Vimos também sobre os padrões definidos pelo GoF (Gang of Four). Aliás, recomendo fortemente que leiam o livro. Nestas próximas partes, vamos analisar detalhadamente cada um dos 23 padrões, suas propostas, quando aplicar, quando não aplicar, vantagens e desvantagens de cada um. Começaremos com o primeiro da lista que apresentei, o Abstract Factory. Abstract Factory O padrão Abstract Factory é o primeiro Pattern descrito no livro Design Patterns do GoF. Ela faz parte da categoria de Patterns Criacionais, cujo objetivo é a instanciação de objetos. Essa categoria é importante, pois ela sustenta o princípio mais importante do livro: “programe para interfaces e não para implementações”. Atualmente, os Patterns Criacionais estão em desuso, sendo substituídos pelos frameworks de Injeção de Dependência, que fazem exatamente isso: instanciam para você as classes das quais você é dependente. De toda forma, conhecer os patterns, sua motivação e entender suas consequências é um bom exercício de design de software. O problema que este padrão tenta resolver é da instanciação na existência de uma família de produtos. O exemplo dado no livro é o seguinte: você tem elementos visuais (produtos), como Window, ScrollBar, Menu e etc. Esses elementos visuais têm diferentes implementações para cada família de implementação gráfica, como o Windows, MAC, e X, do Linux. Nesse caso, a solução consiste em duas partes: Mas de onde virá essa Factory? Em algum lugar, provavelmente na inicialização do seu sistema, você define qual Abstract Factory você vai fornecer ao sistema, e repassa essa Factory a todos os objetos que dependem dela. Veja o esquema: Diagrama UML com exemplo de uso de uma Abstract Factory A figura acima, retirada do livro o Client, representa os demais módulos do sistema, utiliza as classes abstratas dos produtos (AbstractProductA e AbstractProductB) e a AbstractFactory, assim como foi explicado. É importante agora analisar os benefícios e malefícios desse pattern. O ponto principal é que o pattern deixa seu sistema independente das diferentes famílias. Ou seja, garante o baixo acoplamento citado anteriormente. Outro ponto positivo é que este pattern permite adicionar, remover ou modificar rapidamente qual família de produtos deseja-se usar. Isso pode até ser feito em runtime, se usado com um pouco de Reflection para instanciar uma fábrica através de parâmetros (ou com um array referenciando as possíveis fábricas). Já um ponto negativo desse pattern, é que a adição ou remoção de um produto da família exige a modificação da AbstractFactory, o que causa um grande overhead, pois deve-se modificar todas as implementações da Factory e o cliente que usa a AbstractFactory. Na verdade, usando Reflection pode até criar um único método “Create” que recebe como parâmetro alguma indicação de qual produto ele deve criar (uma string com o nome da classe, por exemplo). Dessa forma, você poderia criar um novo produto sem muitos problemas – basta passar o parâmetro certo. Mas isso funciona como uma balança: se você ganha flexibilidade na criação de novos produtos, você perde com a necessidade de uma interface única para todos esses produtos, já que eles serão retornados pelo mesmo método “Create”. E o seu Client precisará fazer uma conversão para o produto específico. Ficha resumo Vamos à “ficha” de definição deste pattern. Diagrama UML com exemplo de uso de uma Abstract Factory public class FabricaAbstrataExemplo { public static void main(String[] args) { FabricaAbstrata fabrica1 = new FabricaConcreta1(); Cliente cliente1 = new Cliente(fabrica1); cliente1.executar(); FabricaAbstrata fabrica2 = new FabricaConcreta2(); Cliente cliente2 = new Cliente(fabrica2); cliente2.executar(); } } class Cliente { private ProdutoAbstratoA produtoA; private ProdutoAbstratoB produtoB; Cliente(FabricaAbstrata fabrica) { produtoA = fabrica.createProdutoA(); produtoB = fabrica.createProdutoB(); } void executar() { produtoB.interagir(produtoA); } } interface FabricaAbstrata { ProdutoAbstratoA createProdutoA(); ProdutoAbstratoB createProdutoB(); } interface ProdutoAbstratoA { } interface ProdutoAbstratoB { void interagir(ProdutoAbstratoA a); } class FabricaConcreta1 implements FabricaAbstrata { @Override public ProdutoAbstratoA createProdutoA() { return new ProdutoA1(); } @Override public ProdutoAbstratoB createProdutoB() { return new ProdutoB1(); } } class FabricaConcreta2 implements FabricaAbstrata { @Override pu
... ++ Mais

TAGS:

Arquitetura desenvolvimento software Parte Abstract Factory iMasterswe developersEm desenvolvimentoclose-circleDigite palavra-chaveEm desenvolvimentoPowered by:Desenvolvimento6 2018Arquitetura desenvolvimento software Parte Abstract Factory449 visualizações COMPARTILHE!Gustavo Bellini BigardiTem artigos publicados 4924 visualizações desde 2018PublicidadeGustavo Bellini Bigardi12editDesenvolvedor arquiteto software mais anos trabalhando tecnologias como .NET Java NodeJS outras. Palestrante eventos comunidade foco tecnologias Microsoft Certificações MCSA MCSD Builder (Microsoft) baterista horas vagas.Leia mais14 2018Arquitetura desenvolvimento software Parte Builder10 2018Arquitetura desenvolvimento software Parte Factory Method29 2018Windows Forms WPF: ainda vale pena?E pessoal! Tudo certo? primeira parte artigo fizemos reflexão papel arquiteto software time como arquitetura software deve algo interesse todos para não exista alguém centralizado onde tudo depende. Vimos também sobre padrões definidos pelo (Gang Four). Aliás recomendo fortemente leiam livro. Nestas próximas partes vamos analisar detalhadamente cada padrões suas propostas quando aplicar quando não aplicar vantagens desvantagens cada Começaremos primeiro lista apresentei Abstract Factory. Abstract Factory padrão Abstract Factory primeiro Pattern descrito livro Design Patterns GoF. parte categoria Patterns Criacionais cujo objetivo instanciação objetos. Essa categoria importante pois sustenta princípio mais importante livro: “programe para interfaces não para implementações”. Atualmente Patterns Criacionais estão desuso sendo substituídos pelos frameworks Injeção

HTML Box Comentário está carregando comentários ...