design patterns (padrões de projeto)...unidade 05 – design patterns (padrões de projeto) 3...

Unidade 05 – Design Patterns (Padrões de Projeto) 1

Análise e Projeto Orientados a ObjetosProf. Edwar Saliba Júnior

Design Patterns(Padrões de Projeto)

Instituto Federal de Educação, Ciência e Tecnologia do Triângulo MineiroProf. Edwar Saliba Júnior

Janeiro de 2020



Pergunta● Qual é a única coisa com a qual

podemos contar no desenvolvimento de software?● Não importa onde você trabalha, o que está

criando ou em que linguagem está programando, qual é a constante que estará sempre com você?– ALTERAÇÃO



Manutenção● Como foi visto no slide anterior, uma das poucas

certezas que você terá sobre o sistema que desenvolver, é a de que ele será alterado em algum momento;

● Alterações podem ser feitas por vários motivos:● implementação de melhorias;● correção de inconsistências;● melhoria de performance e/ou utilização de

recursos e● etc.



Padrões de Projeto● Um Padrão de Projeto (PP) nomeia, abstrai e identifica os

aspectos-chave de uma estrutura de projeto comum para torná-la útil para a criação de projeto orientado a objetos reutilizável;

● O PP identifica as classes e instâncias participantes, seus papéis, colaborações e distribuição de responsabilidades;

● Cada PP focaliza um problema ou tópico particular de projeto orientado a objetos;

● O PP descreve em que situação pode ser aplicado, se ele pode ser aplicado em função de outras restrições de projetos e as consequências, custos e benefícios de sua utilização.

Gamma et al. (2000, p. 20)



Padrão Observer● Contextualização:

● Você sabe como as assinaturas de jornais e revistas funcionam?

● Funcionam assim:

– uma editora começa a publicar jornais;

– você assina o jornal de uma editora e sempre recebe as novas edições;

– enquanto você for assinante, continuará recebendo as novas edições;

– você cancela a assinatura e os jornais param de ser entregues;

– enquanto a editora continua no negócio, entregando para hotéis, pessoas, companhias aéreas e etc.

Adaptado de Freeman e Freeman (2007, p. 56)



Padrão Observer● Editora + assinantes = “padrão observer”

● Se você entende a assintura de jornais, deve entender o padrão observer, onde chamamos a editora de SUBJECT e os assinantes de OBSERVER.


Os objetos OBSERVERque foram registrados (assinaram) no objeto

SUBJECT, receberãoas atualizações, quan-

do elas ocorrerem.

O objeto SUBJECTgerencia dados e,

sempre que houvermudanças, ele

notifica os objetosOBSERVER. Os objetos que não

foram registrados (ou não assinaram) no objeto SUBJECT, não receberão

as atualizações.



Padrão Observer



Padrão Observer● Exemplo utilizando recursos que

funcionam até o Java 8:● código-fonte

● Exemplo utilizando recursos que funcionam do Java 9 em diante:● código-fonte

APOO_Unidade_05_DesignPatterns_Observer_Deprecated.pdf

APOO_Unidade_05_DesignPatterns_Observer_Alternativo.pdf



Padrão Decorator● Contextualização:

● O Starbuzz Coffe, ficou conhecido como a lanchonete com o crescimento mais rápido da região. Se você já viu um na sua esquina, olhe para o outro lado da rua: você verá outro;

● Como eles expandiram muito rápido, estão tendo dificuldade de atualizar seu sistema de pedidos para corresponder a suas ofertas de bebidas;

● Quando entraram no negócio, projetaram as classes do sistema assim (próximo slide):




Padrão Decorator● Diagrama parcial do sistema:


Observe que o método “cost” está em itálico. Ou seja, é um

método abstrato.

Cada método “cost” calcula o preço dotipo do café que

representa.



Padrão Decorator● Na Starbuzz Coffe, além do seu café, você também pode pedir

vários complementos, como:

1) leite com espuma,

2) soja e/ou

3) moca (também conhecido como chocolate) misturado com leite batido;

● Como o Starbuzz cobra um valor para cada complemento, então, eles realmente precisam incluí-los no sistema de pedidos;

● No próximo slide você verá uma alternativa criada para incluir os 3 complementos no sistema. Ao verificar o diagrama, pense no que seria necessário para incluirmos mais um complemento (caramelo ou toffee em inglês) no sistema.




Padrão Decorator


Cada método “cost” calcula o preço dotipo do café mais o

preço do(s) complemento(s).



Padrão Decorator● Se você calculou bem, então, descobriu

que para colocarmos mais um complemento no sistema:● o caramelo (toffee)

seria necessário a criação de mais 32 subclasses;

● Já pensou se tivéssemos que colocar mais 10 complementos?



Padrão Decorator● Para o problema anterior, ainda há uma outra

solução:

Para esta soluçãoo método “cost”

agora é ummétodo normal.Ou seja, possuiimplementação.

O método “cost” aqui, calculará o

preço do(s) complemento(s).

Cada método “cost” das subclasses

somará o preço dotipo do café mais o

preço devolvidopelo método “cost”

da superclasse..




Padrão Decorator● Princípio de Projeto de Software:

“As classes devem estar abertas para extensão, mas fechadas para modificação.” (Freeman e Freeman, 2007, p. 86)



Padrão Decorator● É fundamental que respeitemos o

“Princípio de Projeto de Software” (do slide anterior);

● Porém, agora temos que acrescentar mais um complemento no sistema:

o caramelo (toffee).

● Como faremos?

Não faremos! Não dá pra fazer.



Padrão Decorator● Para casos como este, usamos então o padrão

Decorator, vamos começar com uma bebida (um objeto) e decorá-la com os complementos (outros objetos):● Por exemplo:

– pegamos um objeto DarkRoast,– decoramos com um objeto Moca,– decoramos também com um objeto Soy e– chamamos o método “cost” para gerar o preço.

● A pergunta é: como decorar um objeto?



Padrão Decorator● Começamos com o objeto DarkRoast

● O cliente quer Moca, então criamos um objeto Moca e englobamos DarkRoast nele

● O cliente também quer Whip, então, criamos um decorator Whip e englobamos Moca nele




Padrão Decorator


Primeiro chamamos“cost” no decoratormais externo, Whip.

1,29

Item Preço

BlackRoast

0,99

Moca 0,20

Whip 0,10

Soy 0,15

0,99

1,19



Padrão Decorator


Os quatro objetosconcretos, um paracada tipo de café.

Classe abstrata.

Método abstrato.

Método abstrato.



Padrão Factory● Contextualização:

● Ao codificar para uma interface, você sabe que pode se isolar de várias alterações que podem acontecer em um sistema;

● o código é escrito para uma interface, ele funcionará com qualquer classe nova que implemente esta interface por meio de polimorfismo;

● Se o código possuir muitas classes concretas (aquelas criadas diretamente com o comando new), então este poderá lhe trazer grandes problemas; porque o código pode ter que ser alterado à medida que novas classes concretas precisarem ser adicionadas;

● Assim, seu código não será “fechado para modificação”. Ou seja, para estendê-lo com novos tipos concretos, ele terá que ser reaberto.




Padrão Factory● Se o seu código

possuir uma classe como esta, então, só poderá ser vendido um único sabor de pizza;




Padrão Factory● Para resolvermos o

problema exposto no slide anterior, basta fazermos a seguinte modificação no código;

● Porém criamos outro problema:

● se criarmos novos sabores de pizzas ou se deixarmos de oferecer algum, teremos que modificar o código preexistente.


Parte quepode variar.

Parte fixa.



● Construindo uma “Simple Factory” de pizzas:

Padrão Factory


Classe abstrata.



● Desta maneira, apesar da modularização, ainda assim, se criarmos ou deixarmos de oferecer pizzas, o código terá que ser alterado.

Padrão Factory


Separamos a parte que

pode variar.



Padrão Factory


Classe abstrata.



● Para deixar o código mais flexível, podemos fazer assim:

Padrão Factory


Eliminamos a classe “SimplePizzaFactory”, o método “createPizza” que estava na

classe migrará para a classe “PizzaStore”e se tornará um método abstrato.

Esta mudança possibilita uma flexibilizaçãopara possíveis alterações no software. Epassa a responsabilidade de “criação de pizza” para as classes que herdarem da

classe PizzaStore, que também é abstrata.



Padrão Factory


Classe abstrata.

Método abstrato.

Classe abstrata.

Esta flexibilização do código-fontepossibilitará a criação de novas lojas“stores” que poderão produzir pizzas

personalizadas, adaptadas, para asua região de atendimento.



Padrão Factory




Padrão Factory● Pode-se utilizar este padrão para tudo

que tem variação, por exemplo, no projeto da pizzaria (mostrado nos slides anteriores), a pizza é composta por:● sauce (molho), que podem ter diversos

tipos e● dough (massa), que também podem ter

diversos tipos.● Para os dois itens acima poderíamos

criar uma Factory para cada um.



Padrão Singleton● Contextualização:

● Singleton especifica que apenas uma instância da classe pode existir, e esta será utilizada por toda a aplicação. Dessa forma temos apenas um ponto de acesso central a esta instância da classe. (OPUS-SOFTWARE, 2020)

● Útil:

● Em conexão com banco de dados, evita-se criar diversas conexões simultâneas;

● E em qualquer situação onde houver problema com várias instâncias de um mesmo objeto.



Padrão Singleton - ClássicoNão é seguropara acessosconcorrentes

múltiplos.



Padrão Singleton - SincronizadoA sincronização garanteque dois segmentos decódigo não executem o

mesmo método ao mesmotempo. Um segmento

aguarda o outro executarpara depois executar.

Tem um elevado custode tempo de

processamento.



Padrão Singleton - Estático

De acordo com Freeman eFreeman (2007, p. 158),

criar e instanciar umSingleton num inicializador

estático, torna o códigoseguro em ambientes

multithreading.



Padrão Singleton - Volatile

Desta forma sincronizamosuma única vez, acabando

com o problema apresentadoanteriormente de morosidade.

Esta implementação sófunciona a partir do

Java 5.

Um atributo “volatile” ésempre atualizado dire-

tamente na memóriaprincipal. Diferentemente

dos demais que podem ficarpor um tempo na memória

cache do processador.(UTLUIZ, 2020)



Padrão SingletonAtributo estático.

Construtor privado.

Método estático.



Padrão Command● Definição:

● O Padrão Command encapsula uma solicitação como um objeto, o que lhe permite parametrizar outros objetos com diferentes solicitações, enfileirar ou registrar solicitações e implementar recursos de cancelamento de operações. (Freeman e Freeman, 2007, p. 178)



Padrão Command● o Command é um padrão no qual um

objeto é usado para encapsular toda informação necessária para executar uma ação ou acionar um evento em um momento posterior. (Wikipédia, 2020)



Padrão Command● Estrutura do padrão:

Adaptado de Wikipédia (2020)



Padrão Command 1



Padrão Command 1

● Apresentação do código-fonte anterior e seu funcionamento, no Eclipse e no S.O.



Padrão Command 2


Controle remoto programável:



Padrão Command 2● O controle remoto do slide anterior é um controle universal

para residências;

● O fornecedor do controle também fornece diversas classes, uma para cada tipo de eletrodoméstico que pode ser controlado pelo controle remoto;

● Assim sendo, temos 2 problemas:

● o controle tem limite de 7 equipamentos, pois, só tem 7 slots programáveis e

● como cada eletrodoméstico foi feito por uma empresa diferente, então, cada qual desenvolveu a classe de controle do equipamento produzido da maneira que lhe conveio, ou seja, sem um padrão (vejamos o slide a seguir).



Padrão Command 2● Vejamos as classes e seus respectivos métodos, dos

diversos aparelhos que poderão ser ligados e desligados pelo controle remoto:



Padrão Command 2● Controle Remoto




Padrão Command 2



Padrão Command 2Classes ConcreteCommand

Interface Command



Padrão Command 2

Classes ConcreteCommand



Padrão Command 2Classes Receivers



Padrão Command 2

Classe Invoker



Padrão Command 2Classe Application



Bibliografia● COLLARES, Paulo. Exemplo do Padrão de Projeto ‘Comando’: Controle

Remoto. Disponível em: <https://www.paulocollares.com.br/programacao/exemplo-do-padrao-de-projeto-comando-controle-remoto/>. Acesso em: 31 jan. 2020.

● FREEMAN, Eric; FREEMAN, Elisabeth. Use a Cabeça! Padrões de Projetos (design Patterns). 2. ed. Rio de Janeiro: Alta Books, 2007.

● GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de Projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000.

● OPUS-SOFTWARE. Singleton Design Pattern: o que é, onde usar e quais as vantagens. Disponível em: <https://www.opus-software.com.br/singleton-design-pattern/>. Acesso em: 28 jan. 2020.

● UTLUIZ. Qual a finalidade do Transient e Volatile no Java?. Disponível em: <https://pt.stackoverflow.com/questions/116047/qual-a-finalidade-do-transient-e-volatile-no-java>. Acesso em: 28 jan. 2020.

● WIKIPÉDIA. Command. Disponível em: <https://pt.wikipedia.org/wiki/Command>. Acesso em: 29 jan. 2020.

design patterns (padrões de projeto)...unidade 05 – design patterns (padrões de projeto) 3...

Documents