Engenharia de

Software
Professor: Fernando Corrêa
e-mail:
fernandocmjunior@terra.com.br
Padrões
 O que é um padrão?
 Maneira testada ou documentada de alcançar um objetivo
qualquer
 Cada padrão descreve um problema que ocorre repetidas
vezes em nosso ambiente, e então descreve o núcleo da
solução para aquele problema, de tal maneira que pode-se
usar essa solução milhões de vezes sem nunca fazê-la da
mesma forma duas vezes
 Os padrões de projeto são descrições de objetos que se
comunicam e classes que são customizadas para resolver
um problema genérico de design em um contexto
específico"
2
Por que aprender padrões?
 Aprender com a experiência dos outros
 Aprender a programar bem com orientação a
objetos
 Desenvolver software de melhor qualidade
 Vocabulário comum
 Ajuda na documentação e na aprendizagem
 Uma prática adjunta aos métodos existentes
 Um alvo para refatoramento
3
Elementos de um padrão
 Nome
 É uma referência que podemos usar para descrever um
problema. Ajuda a na implementação e comunicação.
 Problema
 Descreve como aplicar o padrão e quando.
 Solução
 Descreve os elementos que compõem o projeto, seus
relacionamentos, suas responsabilidades e colaborações.
 Conseqüências
 São os resultados e análises das vantagens e
desvantagens da aplicação do padrão.

4
Trabalho
 Identificar os Elementos dos Padrões
(nome,problema, solução).
 Exemplificar e justificar com o trabalho do
laboratório a utilização ou não do padrão.
 Apresentação do trabalho.
 Trabalho Escrito.
 Contextualizar o projeto de laboratório.
 Objetivo.
 Resumo.
 Diagrama de Domínio.
 Diagrama de Caso de Uso (contexto).

5
Padrões
 Abstract Factory: Fornece uma interface para criação de famílias de
objetos relacionados ou dependentes sem especificar suas classes
concretas.
 A fábrica permite a troca de toda uma coleção de classes sem grandes
modificações no programa fonte. Quem conhece as classes concretas é
somente a fábrica.
 O padrão Abstract Factory foi utilizado para que o sistema tivesse
portabilidade em relação ao SGDB utilizado.

 Adapter: Converte a interface de uma classe em outra interface

esperada pelos clientes. O Adapter permite que certas classes
trabalhem em conjunto, pois de outra forma seria impossível por causa
de suas interfaces incompatíveis.
 Usar uma classe existente, mas sua interface não corresponde à interface
de que necessita.
 O padrão Adapter foi utilizado para prover uma interface mais adequada em
certas situações para as classes correspondentes aos objetos persistentes.

6
Padrões
 Bridge: Separa uma abstração da sua implementação, de modo
que as duas possam variar independentemente.
 Separar a interface da sua implementação. Ex: Pessoa, inclusão
de novas pessoas.

 Builder: Separa a construção de um objeto complexo da sua

repesentação, de modo que o mesmo processo de construção
possa criar diferentes representações.
 O algoritmo para criação de um objeto complexo deve ser
independente das partes que compõem o objeto e de como elas
são montadas.
 Para atender esse requisito utilizamos o padrão de projeto
Builder, ou seja, separamos o processo de produção do
relatório da lógica de construção de texto nos diferentes
formatos

7
Padrões
 Chain of responsability: Desacoplar remetentes e
receptores fornecendo a múltiplos objetos a
oportunidade de tratar uma solicitação. A solicitação
é passada ao longo de uma cadeia de objetos até
que um deles a trate. Ex: Help.
 O objeto a ser tratado e selecionado automaticamente.
 Command: Encapsular uma solicitação como um
objeto. Pode parametrizar clientes com vários tipos
de solicitação.
 O padrão Command foi utilizado na
implementação das telas para desacoplá-las dos
objetos que realmente executam as operações
solicitadas a elas Ex: Função / botão.
8
Padrões
 Composite: Compões Objetos em estrutura de
árvore para representar hierarquias do tipo partes-
todo. Ex: Hierarquia do módulo de segurança.
 Decorator: Atribui responsabilidades adicionais a
um objeto dinamicamente.
 Façade: Fornece uma interface unificada para um
conjunto de interfaces em um subsistema. O façade
define uma interface de nível mais alto que torna o
subsistema mais fácil de usar. Ex: Fornecer uma
interface simples para um sistema complexo.
 Oferecer uma interface única de nível mais elevado para
um conjunto de interfaces de um subsistema.

9
Padrões
 Factory Method: Define uma interface para criar um objeto, mas deixa as
subclasses decidirem qual classe a ser instânciada.
 Uma classe não pode antecipar a classe de objetos que deve criar. Sabe que uma
classe tem que ser criada, mas não sabe o tipo. Ex: Documento.
 Iterator: Fornece uma maneira de acessar sequencialmente os elementos de
um objeto agregado sem expor sua representação subjacente. Ex: Lista
acessar seus elementos sem expor a sua extrutura interna. Percorrer a lista. Ex:
Lista de Pedidos de Compra.
 Mediator: Define um objeto que encapsula como um conjunto de objetos
interage. O mediator promove o acoplamento fraco ao evitar que os objetos se
refiram explicitamente uns aos outros, permitindo que você varie suas
interações independentemente.
 Um objeto pode ter que ter o conhecimento de vários outros. Esta comunicação pode
ser complexa e de difícil reutilização.
 Memento: Sem violar o encapsulamento, captura e externaliza um estado
interno de um objeto, de modo que o mesmo possa ser posteriormente
recuperado. Um padrão para trabalhar com estado do objeto. Necessidade de
recuperar um determinado Estado.

10
Padrões
 Observer: Define uma dependência um-para-muitos entre
objetos, de modo que, quando um objeto muda de estado, todos
os seus dependentes são automaticamente notificados e
atualizados. Usar quando uma mudança em um objeto exige
mudanças em outros.
 Singleton: Garante que uma classe tenha somente uma
instância e fornecer um ponto global de acesso para ela. Deve
haver apenas uma instância de uma classe. Exemplo : uma
classe de conexão com o banco de dados.
 State: Permite que um objeto altere seu comportamento quando
seu estado interno muda. O comportamento do objeto depende
do seu estado.
 Strategy: Definir uma família de algoritmos, encapsular cada
uma delas e torná-las intercambiáveis. Permite que o algoritmo
varie independentemente dos clientes que utilizam.

11
Padrão
 Todos – Apreentação Dia XX/11.
 Adapter – interface para um objeto – formas de apresentar.
 Singleton – Classe de Conexão com o Banco de Dados.
 Façade – interface simples para um sistema mais
complexo.
 Vendas
 Abstratct Factory - Ex: portabilidade entre bancos
 Financeiro
 Factory Method – Ex : Tipo de Documento.
 Gerencial
 Composite – ex : hierarquia de segurança.

12
Padrão
 Comportamentais – Apresentação 24/10.
 Grupo de Vendas – Financeiro Lab 1.
 Chain of responsability – Ex : help.
 Observer – controle de atualização de um-para-muitos
 Command – ex : função / botão – Salvar.
 Iterator – Ex : Lista de pedidos de comprar, como acessar.
 Financeiro Lab 2 – Grupo Gerencial 24/10.
 Mediator – um objeto conhecer vários outros. Como
implementar para facilitar o reuso.
 Memento – Trabalhar com o estado do objeto.
 State – Mudança de comportamento.
 Strategy – algoritmos.

13
 Vendas Lab1.
 Builder.
 Interpreter
 Vendas Lab2.
 Prototype.
 Interpreter
 Financeiro Lab1.
 Bridge.
 Template Method.
 Financeiro Lab2.
 Decorator.
 Template Method.
 Gerencial Lab1.
 Flyweight.
 Visitor
 Gerencial Lab2.
 Proxy.
 Visitor.

14
O padrão abstract factory
 Provê uma interface para criação de famílias de objetos relacionados ou
dependentes sem que se especifiquem suas classes concretas.
 Deve ser utilizado principalmente quando se deseja transparência para o
sistema em relação à criação de produtos, quando existirem famílias de
produtos e o sistema deve ser configurado com somente uma delas e quando
houver a necessidade de que sejam utilizados em um sistema somente objetos
de uma mesma família.
 AbstractFactory: classe abstrata que provê uma interface comum de
operações a serem especializadas pelas classes concretas
ConcreteFactory1 e ConcreteFactory2.
 ConcreteFactory: classes concretas derivadas de AbstractFactory que
provêem a implementação dos métodos desta última, instanciando os
respectivos produtos especializados das classes AbstractProduct.
 AbstractProduct: declara uma interface abstrata para os produtos a serem
criados pelas respectivas classes concretas.
 ConcreteProduct: define os produtos a serem criados pelas respectivas
classes concretas e implementa a interface de AbstractProduct
 Client: utiliza apenas as interfaces declaradas pro AbstractProduct e
AbstractFactory.
15
O Padrão abstract factory

16
O Padrão Factory Method
 Permite a definição de uma interface (o factory
method) em uma classe mãe abstrata que, em suas
subclasses, especializa-se para criar vários tipos de
objetos. Deve-se utilizá-lo principalmente quando
existem vários tipos possíveis de objetos a serem
criados por uma classe, mas ela não é capaz de
definir as classes destes objetos. Assim ela delega
esta responsabilidade a subclasses, que vão
particularizar o factory method para criar seus
respectivos objetos.

17
O Padrão Factory Method

18
O padrão Singleton
 Singleton
 Garante que uma classe tenha somente uma instância.
 define operação Instance que permite ao cliente acessar
uma instância única
 Adapter
 Converte a interface de uma classe em outra.
 Target: define a interface a ser utilizada pelos clientes.

 Adaptee: interface a ser adaptada

 Adapter: adapta a interface de Adaptee à interface de

target

19
Singleton / Adapter

20
 Composite
 Compõe objetos em estruturas de árvore de forma a
representar estruturas todo-parte.
 Facade
 Provê uma interface unificada para para um conjunto de
interfaces do sistema.Ele define uma interface de nível
mais alto que torna o sistema mais fácil de ser utilizado
 Sabe quais classes são responsáveis por uma solicitação

 Delega solicitações de clientes aos objetos corretos

 delegates client requests to appropriate subsystem objects.

21
Composite

22