aula 05 - uml e padrões de projeto

Especialização em Desenvolvimento Java UML e Padrões de Projetos

AULA 05 – PADRÕES DE CRIAÇÃO

Prof. Vinícius de Paula -‐ [email protected]

Padrões de Criação

Factory Method ObjeNvo segundo o GoF:

UML e Padrões de Projeto Centro Universitário do Triângulo 3


•  Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar.




•  Factory Method permite que uma classe delegue a responsabilidade de instanciação às subclasses.




•  Factory Method permite que uma classe delegue a responsabilidade de instanciação às subclasses.


Encapsular a escolha da classe concreta a ser utilizada na criação de objetos de um determinado tipo.

Factory Method


Estrutura do Factory Method, segundo GoF (pág. 122)

Factory Method



Classe ou interface que define o objeto a

ser criado

Factory Method




ser criado

Uma implementação parNcular do Npo de objeto a ser criado

Factory Method





ser criado

Classe ou interface que define a assinatura do

método responsável pela criação do produto

Factory Method





ser criado

Classe ou interface que define a assinatura do

método responsável pela criação do produto

Classe que implementa ou sobrescreve o

método de criação do produto

Factory Method Cenário Prá9co

Considere um sistema bancário que precisa enviar mensagens aos seus clientes. Por exemplo, após a realização de uma compra com cartão de crédito, uma mensagem contendo informações sobre a compra pode ser enviada ao cliente.



Considere um sistema bancário que precisa enviar mensagens aos seus clientes. Por exemplo, após a realização de uma compra com cartão de crédito, uma mensagem contendo informações sobre a compra pode ser enviada ao cliente.

Se esse cliente for uma pessoa \sica, poderá́ optar pelo recebimento da mensagem através de e-‐mail ou SMS. Por outro lado, se for uma pessoa jurídica, poderá́ também receber a mensagem através de JMS.




Cada mecanismo de envio será implementado por uma classe. Podemos criar uma interface para padronizar essas classes e obter polimorfismo entre seus objetos.


Neste aspecto quando for necessário enviar uma mensagem, podemos uNlizar diretamente os emissores.





Emissor emissor = new EmissorSMS(); emissor.envia("UML e Padrões de Projeto");

Emissor emissor = new EmissorEmail(); emissor.envia("UML e Padrões de Projeto");

Emissor emissor = new EmissorJMS(); emissor.envia("UML e Padrões de Projeto");







Enviando uma mensagem por SMS








Enviando uma mensagem por Email








Enviando uma mensagem por JMS

Enviando uma mensagem por Email







Crie uma classe para testar os emissores.

Factory Method


public class TestaEmissor1 {

public static void main(String[] args) {

Emissor emissor;

emissor = new EmissorSMS(); emissor.envia("UML e Padrões de Projeto");

emissor = new EmissorEmail(); emissor.envia("UML e Padrões de Projeto");

emissor = new EmissorJMS();emissor.envia("UML e Padrões de Projeto");

}}

Factory Method




Emissor emissor;

emissor = new EmissorSMS(); emissor.envia("UML e Padrões de Projeto");

emissor = new EmissorEmail(); emissor.envia("UML e Padrões de Projeto");

emissor = new EmissorJMS();emissor.envia("UML e Padrões de Projeto");

}}

Utilizando esta abordagem, o código que deseja enviar uma mensagem referencia diretamente as classes que implementam os mecanismos de envio.

Factory Method •  Para eliminar essa referência direta podemos adicionar um intermediário entre o código que deseja enviar uma mensagem e as classes que implementam os emissores.


Factory Method •  Para eliminar essa referência direta podemos adicionar um intermediário entre o código que deseja enviar uma mensagem e as classes que implementam os emissores.

•  Esse intermediário será responsável pela escolha da classe concreta a ser uNlizada para criar o Npo de emissor adequado.


Factory Method


public class EmissorCreator {

public static final int SMS = 0;public static final int EMAIL = 1;public static final int JMS = 2;

public Emissor create(int tipoEmissor) {

if(tipoEmissor == EmissorCreator.SMS) {

return new EmissorSMS();

} else if (tipoEmissor == EmissorCreator.EMAIL){

return new EmissorEmail();

} else if (tipoEmissor == EmissorCreator.JMS){

return new EmissorJMS();

} else {

throw new IllegalArgumentException("Tipo de Emissor não suportado");}

}}

Factory Method











} else {


}}

Definimos uma classe intermediária que será responsável pela criação dos emissores, tornando a classe que utiliza os emissores menos dependente dos mecanismos de envio.

Factory Method











} else {


}}

Altere a classe de teste dos emissores para utilizar a classe EmissorCreator.

Factory Method




Emissor emissor1, emissor2, emissor3;

EmissorCreator creator = new EmissorCreator();

emissor1 = creator.create(EmissorCreator.SMS);emissor1.envia("UML e Padrões de Projeto");

emissor2 = creator.create(EmissorCreator.EMAIL);emissor2.envia("UML e Padrões de Projeto");

emissor3 = creator.create(EmissorCreator.JMS);emissor3.envia("UML e Padrões de Projeto");

}}

Factory Method •  E se a parNr de agora o sistema Nvesse que trabalhar com dois Npos diferentes de envio de mensagens: síncrono e assíncrono.



•  Como poderíamos especializar o criador de emissores?





Definindo subclasses

Factory Method •  Com base no novo cenário, novos produtos precisam ser implementados.


Factory Method


Factory Method


Implemente as classes necessárias para testar a especialização do criador de emissores.

Estrutura do Factory Method




Emissor



Emissor

EmissorAssincronoSMS

EmissorAssincronoJMS

EmissorAssincronoEmail



Emissor




EmissorSincronoSMS

EmissorSincronoEmail

EmissorSincronoJMS



Emissor




EmissorSincronoSMS


EmissorSincronoJMS

EmissorCreator



Emissor




EmissorSincronoSMS


EmissorSincronoJMS

EmissorCreator

EmissorAssincronoCreator

EmissorSincronoCreator

Factory Method





EmissorCreator creator = new EmissorSincronoCreator();


emissor2 = creator.create(EmissorCreator.EMAIL);emissor2.envia("UML e Padrões de Projeto"); emissor3 = creator.create(EmissorCreator.JMS);emissor3.envia("UML e Padrões de Projeto");

}}

Factory Method





EmissorCreator creator = new EmissorSincronoCreator();


emissor2 = creator.create(EmissorCreator.EMAIL);emissor2.envia("UML e Padrões de Projeto"); emissor3 = creator.create(EmissorCreator.JMS);emissor3.envia("UML e Padrões de Projeto");

}}

Factory Method permite que uma classe delegue a responsabilidade de instanciação às subclasses.

Onde podemos ver o uso do Factory Method? •  javax.xml.parsers


Onde podemos ver o uso do Factory Method? •  java.sql.DriverManager


Abstract Factory

Abstract Factory ObjeNvo segundo o GoF:



•  Prover uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.



•  Prover uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.


Encapsular a escolha das classes concretas a serem utilizadas na criação de objetos de diversas famílias.

Abstract Factory


Estrutura do Abstract Factory, segundo GoF (pág. 101)

Abstract Factory



Interface que define as assinaturas dos métodos responsáveis pela criação dos objetos de uma família.

Abstract Factory




Classe que implementa os métodos de criação dos objetos de uma família.

Abstract Factory





Interface que define um Npo de

produto

Abstract Factory





Implementação parNcular de um Npo de produto

Interface que define um Npo de

produto

Abstract Factory Cenário Prá9co

Estabelecimentos comerciais normalmente oferecem aos clientes diversas opções de pagamento. Por exemplo, clientes podem efetuar pagamentos com dinheiro, cartões de crédito ou débito, entre outros.



Estabelecimentos comerciais normalmente oferecem aos clientes diversas opções de pagamento. Por exemplo, clientes podem efetuar pagamentos com dinheiro, cartões de crédito ou débito, entre outros.

Pagamentos com cartão são realizados por meio de uma máquina de cartão, oferecida e instaladas por empresas como Cielo e Redecard. Geralmente, essa máquina é capaz de lidar com cartões de diferentes bandeiras (como Visa e Mastercard).



Nosso objeNvo é programar essas máquinas, isto é, desenvolver uma aplicação capaz de se comunicar com as diferentes bandeiras e registrar pagamentos.



Nosso objeNvo é programar essas máquinas, isto é, desenvolver uma aplicação capaz de se comunicar com as diferentes bandeiras e registrar pagamentos.

No momento do pagamento, a máquina de cartão deve enviar informações relaNvas à transação (como valor e senha) para a bandeira correspondente ao cartão uNlizado. Além disso, a máquina deve aguardar uma resposta de confirmação ou recusa do pagamento.


Abstract Factory •  Nossa aplicação será composta por objetos emissores e receptores de mensagens.



•  Como o protocolo de comunicação de cada bandeira é diferente, teremos um emissor e um receptor para cada bandeira.



•  Como o protocolo de comunicação de cada bandeira é diferente, teremos um emissor e um receptor para cada bandeira.

•  Criaremos fábricas específicas para cada bandeira que serão responsáveis pela criação dos emissores e receptores.


Abstract Factory


Abstract Factory


Implemente as classes necessárias para testar o cenário proposto.

Abstract Factory


1

2

3 4

Abstract Factory


Abstract Factory


Interface que todas as fábricas concretas devem implementar, o que consiste em um conjunto de métodos para fabricar produtos.

Abstract Factory



As fábricas concretas implementam as diferentes famílias de produtos. Para criar um produto o

cliente usa uma destas fábricas.

Abstract Factory



As fábricas concretas implementam as diferentes famílias de produtos. Para criar um produto o

cliente usa uma destas fábricas.

Esta é a família de produtos, cada fábrica concreta pode produzir um

conjunto inteiro de produtos.

Abstract Factory


public class TestaComunicadorFactory {


ComunicadorFactory comunicadorFactory = new VisaComunicadorFactory();

Emissor emissor = comunicadorFactory.createEmissor();

String transacao = "Valor=100;Senha=1234";emissor.envia(transacao);

Receptor receptor = comunicadorFactory.createReceptor();

String mensagem = receptor.recebe(); System.out.println(mensagem);

}}

Abstract Factory + Factory Method E se quiséssemos combinar os dois padrões?



•  As implementações de Abstract Factory podem acionar os Factory Methods para criar emissores e receptores.





public class VisaComunicadorFactory implements ComunicadorFactory {

private EmissorCreator emissorCreator = new EmissorCreator(); private ReceptorCreator receptorCreator = new ReceptorCreator();

public Emissor createEmissor() {

return emissorCreator.create(EmissorCreator.VISA);

} public Receptor createReceptor() {

return receptorCreator.create(ReceptorCreator.VISA);

}}




public class VisaComunicadorFactory implements ComunicadorFactory {

private EmissorCreator emissorCreator = new EmissorCreator(); private ReceptorCreator receptorCreator = new ReceptorCreator();

public Emissor createEmissor() {

return emissorCreator.create(EmissorCreator.VISA);

} public Receptor createReceptor() {

return receptorCreator.create(ReceptorCreator.VISA);

}}

Altere a implementação de forma que os emissores e receptores sejam criados por Factory Methods

Padrão DAO • O padrão DAO (Data Access Object) tem como objeNvo construir uma camada de acesso aos dados de forma a isolar a camada do modelo da camada de persistência.


DB

LDAP

M1

M2

Persistência Classes do Modelo

DAO

Padrão DAO Alguns beneMcios de se u9lizar o padrão DAO:

•  O mecanismo de persistência pode ser alterado a qualquer momento sem ter que modificar a camada de modelo.

•  Vários mecanismos de persistência podem ser uNlizados de forma transparente para o cliente.

•  Com o padrão DAO, podemos abstrair e encapsular o acesso às fontes de dados. - Gerencia a conexão com a fonte e sabe como obter os dados.


Trabalho Construa uma aplicação contendo operações CRUD para um determinado cenário de negócio.


Trabalho Construa uma aplicação contendo operações CRUD para um determinado cenário de negócio. ü Deverá ser implementado um DAO Factory para instanciar as formas de persistência suportadas pela aplicação, no contexto do trabalho, pelo menos duas.



ü Uma interface gráfica amigável deverá ser construída.



ü Uma interface gráfica amigável deverá ser construída.


Artigo para auxiliar na definição da arquitetura da aplicação. http://www.informit.com/guides/content.aspx?g=java&seqNum=442

Bibliografia •  Gamma, Erich; Richard Helm, Ralph Johnson, John M. Vlissides . Design pagerns: elements of reusable object-‐oriented sohware. Reading: Addison-‐Wesley, 1995.

•  Erich Freeman, Elizabeth Freeman. HeadFirst – Design Pagerns. O ́REILLY 2004.

• METSKER, J. Design Pagerns Java Workbook. EUA: Addison-‐Wesley 2002.

•  K19 Treinamentos, “Design Pagerns em Java”.


aula 05 - uml e padrões de projeto

Education