UML OO Design Patterns

ANÁLISE E PROJETO ORIENTADO A
OBJETOS COM MODELAGEM
WEB UTILIZANDO UML
M.Sc. Engº Alex Pinheiro das Graças

CONCEITOS AVANÇADOS DE
ORIENTAÇÃO A OBJETOS
Padrões de Projetos ou Design Patterns

PADRÃO DE PROJETOS
Cada padrão descreve um problema que ocorre e se
repete em nosso ambiente e então descreve o
núcleo de uma solução para aquele problema de
forma que você pode utilizar esta solução um
milhão de vezes sem repeti-la duas vezes que seja.
(Alexander, 77 apud Gamma et. al, 1995, pg. 2)

M.Sc. Alex Pinheiro das Graças - 2012

PADRÃO DE PROJETOS
 Ganhou popularidade, na área da computação,
com o livro Design Patterns: Elements of Reusable
Object-Oriented Software lançado em 1995 por
Erich Gamma, Richard Helm, Ralph Johnson e
John Vlisfsides.
 Conhecidos como Gang of Four


TIPOS DE PADRÕES
Process Patterns: Building Large-Scale
De processos Systems Using Object TechnologyScott W.
de Software Amblerhttp://www.ambysoft.com/books/proces
sPatterns.html

Core J2EE™ Patterns: Best Practices and
Arquiteturais Design Strategies Deepak Alur, John Crupi e
Dan Malks

Padrões
De Modelagem Analysis Patterns: Reusable
O.O. Object Models Martin Fowler

Design Patterns Erich Gamma
De Projeto Erich Gamma, Richard Helm,
Ralph Johnson e John Vlissides

Orientados a Patterns in Java™, Volume 1
Linguagens Mark Grand


PADRÃO DE PROJETOS
 Um Padrão de Projeto é uma solução consolidada
para um problema recorrente no desenvolvimento e
manutenção de software orientado a objetos.


BENEFÍCIOS
 Padrões de Projetos possuem dois benefícios
principais:
1. Fornecem uma forma de resolver problemas
relacionados com o desenvolvimento de software
utilizando soluções comprovadas.
2. Design patterns tornam a comunicação entre
projetistas/arquitetos mais eficiente.


BENEFÍCIOS
 Resposta às perguntas
 Qual a Granularidade?
 Quais Classes implementar?
 Qual a interface das Classes?
 Implementação?


ENTRETANTO...
 Padrões de projetos adicionam flexibilidade no seu
software entretanto adicionam camadas extras;
 PODE Complicar o projeto;
 PODE Impactar a Performance;


PADRÕES DE PROJETOS
 Os padrões de projetos são divididos em três
grandes famílias:
 De Criação
 Estrutural
 Comportamental


CRIAÇÃO
 Encapsula qual a classe concreta que o sistema
utiliza;
 Aumenta a flexibilidade
 Qual objeto é criado?
 Como o objeto é criado?


CRIAÇÃO - CATÁLOGO
 Abstract Factory
 Builder

 Factory Method

 Prototype

 Singleton


FACTORY METHOD

Define uma interface para criar um objeto, mas deixa
a subclasse decidir qual classe instanciar. Factory
Method adia a instanciação das classes, deixando
essa tarefa para as subclasses.


FACTORY METHOD


ABSTRACT FACTORY
 Problema:
 Criar famílias de objetos relacionados entre si.
 O sistema pode escolher famílias de objetos diferentes.
 Não podem ser instanciados partes de famílias
diferentes.
 Exemplo:
 Um jogo que de corrida com várias épocas,
dependendo da época que é escolhida, os carros terão
determinada aparência e propriedades.


ABSTRACT FACTORY

Provê uma interface para criar famílias de Objetos
relacionados ou dependentes sem especificar as
classes concretas.


ABSTRACT FACTORY


ABSTRACT FACTORY
 AbstractFactory
 Declara uma interface para operações de criação;
 ConcreteFactory
 Implementa as operações de criação
 AbstractProduct
 Declara uma interface para o objeto criado
 ConcreteProduct
 Define o objeto a ser criado por uma ConcreteFactory


ABSTRACT FACTORY
 Quando usar
 Um sistema deve ser configurado com múltiplas
famílias de produtos;
 Uma família de classes deve ser usada juntas;
 Você deseja revelar apenas os produtos e não suas
implementações;


SINGLETON

Força a existência de apenas uma instância da
classe e provê um ponto padrão de acesso.


SINGLETON

 Construtor é privado;
 O atributo singleton e o método
getInstance são estáticos;
 Os outros atributos e
operações da Classe não são
estáticos

 Cada vez que esse método for chamado,
ele deve checar se já existe uma
instância da classe e retorná-la, caso
contrário, ele deve instanciar a classe,
guardar a referência ao objeto no atributo
estático da classe e então retorná-lo.

SINGLETON


PADRÕES ESTRUTURAIS
 Esses padrões de projeto estão interessados em
como classes e objetos estão dispostos para
formar estruturas maiores.


PADRÕES ESTRUTURAIS - CATÁLOGO
 Adapter
 Bridge

 Composite

 Decorator

 Facade

 Flyweight

 Proxy


PROXY

Provê um substituto ou um espaço reservado para
outro objeto com o intuito de controlar o acesso a
este objeto.


PROXY


PROXY
 Proxy
 Mantém uma referência que deixa o proxy acessar o
objeto real.
 Prove uma interface identica ao objeto real.
 Controla acesso para o objeto real e pode ser
responsável por criá-lo.
 Subject
 Define uma interface comum.
 RealSubject
 Define o objeto real que será representado pelo Proxy


PROXY
 Exemplos de utilização
 Hibernate: quando o hibernate carrega objetos em
modo lazy ele traz proxy dos objetos.
 Java RMI cria proxies para fazer acesso remoto.
 Quando estamos utilizando uma conexão lenta e vemos
somente uma quadrado para a figura estamos vendo
um proxy.
 Segurança, o proxy pode ser utilizado para averiguar o
usuário autenticado e somente após a verificação
chamar a função pretendida.


COMPOSITE

Compões objetos em árvore para representar
hierarquias todo-parte. Composições leva clientes a
tratar objetos individuais e composições da mesma
maneira.


COMPOSITE


COMPOSITE
 Participantes
 Componente
 Interface dos componentes

 Folha
 Representa folhas da árvore

 Composição
 Define o comportamento de componentes que tem

filhos
 Cliente
 Manipula os objetos a partir da interface de

Componente


DECORATOR
 Problema
 Necessidade de adicionar responsabilidade em tempo
de execução a um objeto.
 Exemplo
 Uma feijoada é adicionado diversos ingredientes.
Quando um ingrediente é adicionado é necessário
modificar o calculo de valor da feijoada.


DECORATOR

Adiciona responsabilidades para um objeto
dinamicamente. Oferece uma alternativa flexível por
meio de subclasses para extender funcionalidade dos
objetos.


DECORATOR


DECORATOR
 Component
 Define a interface para o objeto que poderá ter
funcionalidades adicionadas.
 ConcreteComponent
 O objeto que poderá ter responsabilidades adicionadas
 Decorator
 Mantêm uma referência para um objeto Component e
define uma interface conforme a interface Component.
 ConcreteDecorator
 Adiciona responsabilidade ao Componente


DECORATOR
 As classes de I/O do JAVA utilizam o padrão
decorator
 As classes básicas são InputStream, OutputStream,
Reader.
 Os comportamentos adicionais são por meio de
decorações
 BufferedStream: adiciona buffers para o Stream
 Data Stream: permite o I/O de tipos primitivos

 Pushback Stream: permite a operação Undo


COMPORTAMENTAL
 Padrões de Projeto comportamentais trabalham
com algoritmos e definição de responsabilidade
entre objetos.


COMPORTAMENTAL - CATÁLOGO
 Command  Visitor
 Observer

 Chain of Responsability

 Interpreter

 Iterator

 Mediator

 Memento

 State

 Strategy

 Template Method


COMMAND
 Problema
 Não é possível prever com antecedência qual a ação de
um objeto;
 Exemplo um controle remoto custumizável
 Necessidade de implementar o comando desfazer;


COMMAND

Encapsula requisições em objetos, possibilitando a
parametrização de clientes para diferente
requisições. Além disso possibilita a criação de
logs, filas e a ação “desfazer”.


COMMAND


COMMAND
 Command
 Declara uma interface para executar uma operação
 ConcreteCommand
 Define um relacionamento entre um objeto Receiver e
uma ação
 Cliente
 Cria um ConcreteCommand e atribui ao receptor
 Invoker
 Pede o comando para executar a requisição
 Receiver
 Sabe como executar as operações. Qualquer classe pode
ser um Receiver


COMMAND - EXTENSÕES
 Criação de filas:
 Utilizado em aplicações síncronas, onde um executor
de comandos pode receber um novo comando
enquanto ainda está executando um comando anterior.
 Exemplo: Native Command Queuing. O HardDisk recebe
várias ações. Podendo ordenar a fila dos comandos para
otimizar o acesso ao disco.


 Desfazer e Refazer:
 Necessidade de criar a funcionalidade de desfazer e
refazer em uma aplicação.
 Exemplo: Criação do comando desfazer em um editor de
Texto.


OBSERVER
 Problema
 Quando um objeto X é modificado, outros objetos
devem ser atualizados para refletir o estado do objeto X
atualizado.


OBSERVER

Define uma dependência um para muitos entre
objetos então quando o estado de um objeto é
modificado, todos os objetos dependentes são
atualizados automaticamente.


OBSERVER


OBSERVER
 Observer
 Define uma interface de atualização para objetos que
devem ser notificados da alteração
 Subject
 Conhece os seus observadores. Qualquer observer pode
observar um Subject
 ConcreteObserver
 Mantem uma referência para um ConcreteSubject
 Implementa a interface de atualização
 ConcreteSubject
 Envia notificação quando o estado do objeto é alterado


EXERCÍCIO
 Modifique as classes,
principalmente o método
measurementsChanged
para utilizar o objeto
WeatherData para
atualizar três exibições:
condições atuais,
Estatísticas e uma
previsão.
 O método atualizar
mostra os valores na
tela.

Baseado no Livro Use a Cabeça - Padrões de Projeto

RESPOSTA EXERCÍCIO
 O conhecimento de
padrões de projetos
leva-nos a encontrar
soluções rapidamente.
 Soluções amplamente
testadas
 Facilitam o
entendimento por
outros programadores.

UML OO Design Patterns

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to UML OO Design Patterns

Similar to UML OO Design Patterns (20)

UML OO Design Patterns