Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense...

46
Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense [email protected]

Transcript of Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense...

Page 1: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

Padrões de Projeto para Software Orientado a Objetos

Professora: Aline Vasconcelos

IF-Fluminense

[email protected]

Page 2: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

 

Page 3: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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]

 

Page 4: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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();

.......................

}

Page 5: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 6: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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)

Page 7: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 8: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 9: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 10: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 11: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 12: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 13: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 14: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

14

EXEMPLOS DE PADRÕES

Page 15: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 16: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 17: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 18: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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;}

Page 19: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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();

Page 20: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 21: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 22: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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();

Page 23: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 24: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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)

Page 25: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 26: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

26

Adapter (Padrão Estrutural)

Estrutura:

Client

Adaptee

specificRequest()

Target

request()

Adaptee a

Adapter

request()a.specificRequest()

request()

Page 27: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 28: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 29: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 30: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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()

Page 31: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 32: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 33: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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()

.........

Page 34: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 35: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 36: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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).

Page 37: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

37

State Pattern - Colaborações

m1:Matricula estado:EstadoMatricula

trancar()

trancar()

setEstado(estadoConcreto = Trancada)[trancou]

Page 38: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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();

Page 39: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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!”);

Page 40: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 41: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 42: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 43: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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

Page 44: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

44

Observer - comportamento

concreteSubject concreteObserver1

setState()

concreteObserver2

notify()

update()

getState()

update()getState()

Page 45: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.

Page 46: Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense apires@iff.edu.br.

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.