Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense...
Transcript of Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense...
Padrões de Projeto para Software Orientado a Objetos
Professora: Aline Vasconcelos
IF-Fluminense
2
Roteiro
Definição de Padrão Categorias de Padrões Exemplo de Padrão Arquitetural Camadas
Seções de Documentação de um Padrão Categorias de Padrões de Projeto Exemplos: Singleton
Adapter
State Pattern
3
Padrão
“Um Padrão descreve um problema que ocorre repetidas vezes em nosso meio e inclui uma solução genérica para o mesmo, de tal maneira que se pode utilizá-la mais de um milhão de vezes, sem nunca fazê-lo de forma idêntica.”
[Cristopher Alexander, 1979]
4
Categorias de Padrões em Engenharia de Software
– Padrões Arquiteturais: expressam
um esquema de organização estrutural
fundamental para sistemas de software.
(BUSCHMANN et al., 1996)
– Padrões de Projeto: disponibilizam
um esquema para refinamento de subsistemas
ou componentes de um sistema de software
(GAMMA et al., 1995)
– Idiomas: descreve como implementar
aspectos particulares de componentes ou de
relacionamentos entre eles, usando as
características de uma dada linguagem
de programação.
public void runServer()
{
ServerSocket server;
Socket connection;
try { connection =
server = new ServerSocket(7000, 100);
.........
server.accept();
.......................
}
5
Padrão Arquitetural: Camadas (1/4)
Uma arquitetura em camadas é organizada hierarquicamente, onde as camadas mais internas provêem serviços às camadas mais externas.
CoreLevel
Base Utility
Useful SystemsAgregados de Elementos Menores
Users
6
Padrão Arquitetural: Camadas (2/4)
Componentes: Camadas Conectores: protocolos que determinam como as Camadas interagem
Regras: limites de interação às Camadas adjacentes.
Exemplos: protocolos de comunicação em camadas (OSI), alguns sistemas operacionais, arquitetura em 3 Camadas para sistemas de informação comerciais (Interface, Negócio, Persistência)
7
Padrão Arquitetural: Camadas (3/4)
GUI
Negócio
Persistência
Exemplo: Arquitetura em 3 Camadas para Sistemasde Informação.
As requisições de serviços são feitas das Camadas maisexternas para as mais internas. As respostas retornam no sentido contrário.
8
Padrão Arquitetural: Camadas (4/4)
Vantagens:– Suporte à Evolução dos Sistemas– Flexibilidade e boa Manutenibilidade
Desvantagens:– Problemas de Desempenho e Comunicação– Complexidade na Implementação do Sistema
9
Descrição de Padrão de Projeto
“Em geral, um padrão possui quatro elementos essenciais”. (GAMMA et al., 1995).
Nome: é uma referência que podemos usar para descrever um problema de projeto, suas soluções e conseqüências em uma ou duas palavras.
Problema:o problema descreve quando aplicar o padrão. Ele é determinado por um sistema de forças, e estas forças estabelecem os aspectos do problema que devem ser considerados. Algumas vezes, o problema incluirá uma lista de condições que devem ser satisfeitas para que faça sentido aplicar o padrão.
10
Descrição de Padrão
Solução: descreve os elementos de projeto, seus relacionamentos, suas responsabilidades e colaborações que proverão uma solução para o problema. A solução não descreve um projeto concreto ou uma implementação particular porque um padrão é como um gabarito que pode ser aplicado em muitas situações diferentes.
Conseqüências:são os resultados e análises das vantagens e desvantagens (trade-offs) da aplicação do padrão. Embora as conseqüências sejam raramente mencionadas quando descrevemos decisões de projeto, elas são críticas para a avaliação de alternativas de projeto e para a compreensão dos custos e benefícios da aplicação do padrão.
11
Descrição de Padrão
Além destes itens de descrição, o Contexto também é extremamente importante na descrição de um padrão:
Contexto: estende o problema a ser solucionado, apresentando situações de ocorrência desse problema.
12
Padrões em ES
Padrões em ES permitem que desenvolvedores possam recorrer a soluções já existentes para solucionar problemas que normalmente ocorrem em desenvolvimento de software.
Surgimento: início dos anos 90.
Padrões capturam experiência existente e comprovada em desenvolvimento de software, ajudando a promover boa prática de projeto.
Padrões criam um vocabulário comum para desenvolvedores de software.
13
Categorias de Padrões de Projeto
Padrões de Criação: abstraem o processo de instanciação, ajudando a tornar um sistema independente de como seus objetos serão criados ou representados.
Padrões Estruturais: se preocupam com a forma como classes e objetos são compostos para formar estruturas maiores e de que forma a alteração na estrutura pode propiciar a extensão ou adequação das funcionalidades do sistema.
Padrões Comportamentais: se preocupam com a atribuição de responsabilidades entre objetos, com o comportamento dos objetos e com questões relacionadas a algoritmos. Os padrões comportamentais não descrevem apenas padrões de objetos ou classes, mas também os padrões de comunicação entre eles.
14
EXEMPLOS DE PADRÕES
15
Singleton (Padrão de Criação)
Nome: Singleton
Problema: garantir que uma classe possuirá somente uma instância ao longo da execução do sistema e fornecer um ponto global de acesso para a mesma.
– O software apresenta uma classe que não necessita ou não deve ser instanciada mais de uma vez.
16
Singleton
Solução:
– Tornar a própria classe responsável por manter o controle sobre a sua única instância.
– A classe pode garantir que nenhuma outra instância será criada, interceptando pedidos de criação de novos objetos.
– A classe deve fornecer um meio para que objetos de outras classes acessem a sua única instância.
– Deve fornecer um ponto de acesso único à sua única instância.
17
Singleton
Estrutura:
Singleton
getInstance()singleton()singletonOperation()
ponto de acesso único;retorna a instânciao construtor
é privado
operações do Singleton
static instancesingletonData
guarda a instânciaúnica
18
Singleton
Implementação:
public class Singleton {
private static Singleton instance = null;
private Singleton() { }
public static Singleton getInstance() {if (instance == null)
instance = new Singleton(); return instance;}
19
Singleton
Colaborações: – Os clientes requisitam serviços ao Singleton
somente através da sua instância única, a qual é obtida pela operação getInstance().
c1: Client s1: Singleton
Singleton.getInstance().singletonOp1();
20
Singleton
Contexto – exemplo de uso:
– Classe Controladora, como ControladorMatricula, por exemplo.
Conseqüências:– Permite controlar o número de instâncias que a
aplicação utiliza.– Mais flexível do que operações de classe. Uma outra
maneira de empacotar as funcionalidades de um Singleton é utilizando operações de classe. Porém, esta técnica torna difícil mudar o projeto para permitir mais de uma instância da classe (menor flexibilidade) e não permite o polimorfismo.
21
Singleton
Exemplo:
ControladorMatricula
+ ControladorMatricula getInstance()- ControladorMatricula() + boolean matriculaAluno()
ponto de acesso único; retorna a instância
o constru-tor é privado
operações do Singleton
-ControladorMatricula instance = null- int passoCasoUsoMatricula
guarda a instânciaúnicadados do
Singleton
22
Singleton
Exemplo: – Os clientes requisitam serviços ao Singleton
somente através da sua instância única, a qual é obtida pela operação getInstance().
c1: GUIMatricular ControladorMatricula
ControladorMatricula.getInstance().matriculaAluno();
23
Singleton
Exemplo:
AcessoBD
+ AcessoBD getInstance()- AcessoBD() + iniciarConexao() + encerrarConexao + incluirBanco(registro, tabela) + excluirBanco(chave, tabela) + consultarBanco (chave, tabela)
operações do Singleton
-AcessoBD instance = null-conexao
guarda a instânciaúnicadados do Singleton
24
Singleton
Exemplo: – Os clientes requisitam serviços ao Singleton
somente através da sua instância única, a qual é obtida pela operação getInstance().
c1: GUICadastro AcessoBD
AcessoBD.getInstance().iniciarConexao();
AcessoBD.getInstance().incluirBanco(registro, tabela)
25
Adapter (Padrão Estrutural)
Nome: Adapter (ou Wrapper)
Problema: converter a interface de uma classe em outra esperada por um cliente.
Permite que classes incompatíveis trabalhem em conjunto – o que, de outra forma, seria impossível.
Permite a criação de classes (ou módulos) reutilizáveis, que cooperam com classes não-relacionadas ou não-previstas.
26
Adapter (Padrão Estrutural)
Estrutura:
Client
Adaptee
specificRequest()
Target
request()
Adaptee a
Adapter
request()a.specificRequest()
request()
27
Adapter
Participantes:– Target: define a interface específica do domínio
que o Cliente precisa.
– Client: colabora (requisita serviços – chama métodos) com objetos compatíveis com a interface de Target.
– Adapter: adapta a interface de Adaptee, que contém os métodos/serviços necessários a Client, à interface de Target.
– Adaptee: define uma interface de classe existente que precisa ser adaptada.
28
Adapter
Solução:– Clientes enviam requisições à Classe
Adaptadora (Adapter) quando na realidade desejam enviar requisições à Classe Adaptada (Adaptee).
– A classe adaptadora (Adapter) define a interface de serviços necessários ao cliente, sendo subclasse de Target.
– As classes adaptadoras (Adapters) chamam os serviços de uma classe adaptada (Adaptee), os quais são de interesse do cliente. Para tanto, guardam uma instância de Adaptee.
29
Adapter
Contexto (exemplo):
Plug-in
Ferramenta CASE
Adaptador
Oferece serviços necessários ao plug-in, mas cujas assinaturas ele desconhece.
O mesmo plug-in deve ser carregado em várias ferramentas CASE.
requisições
requisições
30
Adapter
Exemplo Aluno:
GUIAluno
Aluno
Classe Aluno desenvolvida para o sistema acadêmicoDo CEFET.
GUIAluno do sistema acadêmico da UFF.
requisições
requisições matricula
nomeendereco
matricularAluno()trancarMatricula()cancelarMatricula()colarGrau()
AdaptadorAluno
Aluno a
matricula()alterarSituacao()formarAluno()enturmar()
a.matricularAluno()a.trancarMatricula()oua.cancelarMatricula()
a.colarGrau()
31
Adapter
Vantagens:
– Aumento da reusabilidade de classes e componentes.
– Encapsulamento dos serviços da classe fornecedora. Modificações na classe fornecedora não afetam o cliente.
Desvantagens:
– Complexidade de implementação.
32
State Pattern (Padrão Comportamental)
Nome: State Pattern
Problema: o comportamento de um objeto depende do seu estado e ele pode mudar o seu comportamento em tempo de execução quando o seu estado muda.
As operações do objeto acabam ficando com muitos comandos condicionais, avaliando o estado do objeto para a escolha de um caminho ou comportamento.
33
State Pattern
Solução: cada ramo do comando condicional deve ser colocado em uma classe separada.
O estado do objeto é tratado como um objeto propriamente dito.
Estrutura:
state.handle()
Context
request()
State
handle()11
ConcreteStateA
handle()
ConcreteStateB
handle()
.........
34
State Pattern: Participantes
Context: define a interface de interesse para os clientes; mantém uma instância de uma subclasse de State (ou seja, uma instância de um ConcreteState) que define o seu estado corrente e comportamento.
State: define uma interface comum de operações para os estados concretos de Context.
ConcreteState: cada subclasse de State representa um estado concreto do objeto Context e implementa comportamentos associados a este estado.
35
Diagrama de Estado do Objeto Matrícula
Início
Em Aberto
Regular
matricular[ docs pendentes ] / emitirComprovante
matricular[ documentação completa ] / emitirComprovante
entrega documento[ docs ok ]
Trancada
reabrir matrícula[ início período ]
Fim
cancelar matrícula
Fim
trancar matrícula[ 1º período completo ]
cancelar matrícula
concluir curso
Fim
cancelar matrícula
State Pattern – Contexto (Exemplo)
Matricula
trancar()cancelar()concluir()entregarDocumento()reabrir()setEstadoMatricula()getEstadoMatricula()
EstadoMatricula
trancar()concluir()entregarDocumento()reabrir()
11
Trancada
trancar()concluir()entregarDocumento()reabrir()
Regular
trancar()concluir()entregarDocumento()reabrir()
EmAberto
trancar()concluir()entregarDocumento()reabrir()
As operaçõestrancar, concluiretc, recebem o próprio objeto matricula comoparâmetro.
A operação setEstadomatricula recebe um objeto do tipo EstadoMatriculacomo parâmetro. A Matrícula possui um atributo estado do tipo EstadoMatricula que guarda uma referência para uma instância de estado concreto (EmAberto, Regular ou Trancada).
37
State Pattern - Colaborações
m1:Matricula estado:EstadoMatricula
trancar()
trancar()
setEstado(estadoConcreto = Trancada)[trancou]
38
State Pattern - Exemplo
A classe Matricula representa o Context.
A classe Matricula guarda uma referência para EstadoMatricula, a qual pode conter uma instância de um dos objetos que representam os estados concretos da matricula.
EstadoMatricula estado; O objeto Matricula, quando da sua criação, decide pela criação
de um objeto de estado “EmAberto” ou “Regular”.
If (docs ok)
estado = new Regular();
else
estado = new EmAberto();
39
State Pattern - Exemplo
Os objetos que representam os estados concretos da Matricula (“EmAberto”, “Regular” e “Trancada”) decidem pela mudança de estado da Matricula. A cada mudança de estado, eles devem atualizar a referência de estado no objeto Matricula. Para tal, a Matricula apresenta uma interface com métodos get e set para seu estado atual.
Exemplo: Estado Regular – método trancar():
if (primeiroPeriodo ok) { EstadoMatricula estadoConcreto = new Trancada(); matricula.setEstadoMatricula(estadoConcreto); } else System.out.println(“Trancamento Inválido!”);
40
State Pattern
Conseqüências:
– Facilidade de evolução do esquema, ou seja, facilidades para o acréscimo de novos estados e novas transições de estado.
– Evita comandos condicionais em toda a implementação de Context (i.e. Matricula).
– Distribui o comportamento para diversos estados e aumenta o número de classes no sistema.
– Torna explícitas as transições de estado.
41
Observer (padrão comportamental)
Problema: definir uma dependência um para muitos entre objetos, de maneira que quando um objeto muda de estado, todos os seus observadores (dependentes) são notificados e atualizados automaticamente.
– Um efeito colateral comum resultante do particionamento de um sistema em uma coleção de classes cooperantes é a necessidade de manter a consistência entre objetos relacionados.
42
Exemplo:Nota 1
0
2
4
6
8
10
12
aaa bbb cccc ddd
Nota 1
Nota 1
aaa
bbb
cccc
ddd
Nota 1
0
2
4
6
8
10
12
aaa bbb cccc ddd
Nota 1
Aaa = 10Bbb = 5,7Cccc = 6,5Ddd = 7,6
43
Observer - Estrutura
Subject
attach(Observer)detach(Observer)notify()
Observer
update()
ConcreteObserverobserverState
update() -> observerState = subject.getState()
Herança
For all observers -> o.update
*
ConcreteSubject
subjectState
getState()setState()
Herança
44
Observer - comportamento
concreteSubject concreteObserver1
setState()
concreteObserver2
notify()
update()
getState()
update()getState()
45
Observer
Participantes:– Subject: conhece os seus observadores. Um número
qualquer de objetos Observer pode observar um Subject.
Fornece uma interface para associar e desassociar observadores.
- Observer: define uma interface de atualização para objetos ConcreteObserver, que devem ser notificados e se atualizar de acordo com as mudanças no Subject.
- ConcreteSubject: armazena dados de interesse para objetos ConcreteObserver.
- ConcreteObserver: mantém uma referência para um objeto ConcreteSubject. Armazena estados que devem estar consistentes com o do Subject. Implementa a interface de atualização do Observer.
46
Observer
Conseqüências:
– Permite variar Subjects e Observers de forma independente.
– Possibilidade de reutilizar observadores e observados independentemente.
– Acoplamento abstrato entre Subject e Observer.
– Suporte para comunicação broadcast: a notificação que um subject envia não necessita especificar seu receptor. A notificação é enviada automaticamente a todos os objetos interessados que se subscreveram.