Design Patterns
Projeto de Sistemas de Software
Leandra Mara da Silva
Motivação
• Aprimorar conhecimentos sobre Projeto de Sistemas de
Software, realizando um estudo incremental dos Padrões de
Projeto apresentados em [GoF].
• Palavras-chave: Engenharia de Software, Projeto de Sistemas de
Software, Padrões de Projeto.
© LES/PUC-Rio
Padrão State
State
• Classificação
– Comportamental de Objeto
• Também conhecido como:
– Objects for States
• Propósito
– Permitir a um objeto alterar o seu comportamento quando o
seu estado interno mudar. O objeto parecerá ter mudado de
classe.
© LES/PUC-Rio
State
• Motivação
Exemplo de Problema:
– Um objeto responde de maneira distinta dependendo do seu
estado
© LES/PUC-Rio
State
Exemplo de Solução:
– Conexão possui um objeto que representa o seu estado e que
executa as tarefas dependentes de estado (polimorfismo).
© LES/PUC-Rio
State
• Aplicabilidade
– O comportamento de um objeto depende do seu estado que é
alterado em tempo de execução
– Operações de um objeto possuem condicionais grandes, de
várias alternativas (sintoma do caso anterior).
Frequentemente, muitas operações irão conter essa mesma
estrutura condicional.
• Estados são usualmente representados por uma ou mais
constantes
• O State coloca cada ramo de comando condicional em uma classe
separada, tratando os estados dos objetos como objetos
propriamente ditos
© LES/PUC-Rio
State
• Estrutura
• Questão: quem define as transições de estado?
© LES/PUC-Rio
State
• Participantes
– Context
• define a interface de interesse para os clientes
• mantém uma instância de uma subclasse ConcreteState que define
o estado corrente
– State
• define uma interface para encapsulamento associado com um
determinado estado do Context
– ConcreteState subclasses
• cada subclasse implementa um comportamento associado com um
estado do Context
© LES/PUC-Rio
State
• Colaborações
– Context delega solicitações específicas de estados para o
objeto corrente ConcreteState
– Um contexto pode passar a si mesmo como um argumento
para o objeto State que trata a solicitação. Isso permite ao
objeto State acessar o contexto, se necessário
– Context é a interface primária para os clientes. Os clientes não
tem que lidar com objetos State diretamente
– Tanto Context quanto as subclasses de ConcreteState podem
decidir qual estado sucede outro
© LES/PUC-Rio
State
• Exemplo de Código
– Situação: usuário de biblioteca quer
pegar empréstimo de livros.
Dependendo do seu estado, o usuário
pode ou não pegar livros
– Classes Envolvidas: UsuarioContexto,
UsuarioState,
UsuarioSemEmprestimo,
UsuarioComEmprestimo,
UsuarioEmDebido
© LES/PUC-Rio
State – Exemplo de Código
© LES/PUC-Rio
State – Exemplo de Código
© LES/PUC-Rio
State – Exemplo de Código
© LES/PUC-Rio
State
– Outros casos exemplos:
• Estados de seleção no Paint (lápis selecionado, balde
selecionado)
• Estados de um projeto em um sistema de gerenciamento de
projetos
© LES/PUC-Rio
State
• Conseqüências
– Separa comportamento dependente de estado.
• pró : Novos estados/comportamentos podem ser facilmente
adicionados e ganho em legibilidade. A intenção sobre as transições
de estado fica mais clara
• Contra: aumento no número de classes; menos compacto
– Transição de estados é explícita
– Objetos States podem ser compartilhados
• Quando não possuem variáves de instância podem ser
compartilhados essencialmente como flyweights, sem estado
intrínseco, somente comportamento
© LES/PUC-Rio
Fim!!