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

Exemplo de Padrão Arquitetural Seções de Documentação de um Padrão 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  

[Cristopher Alexander, 1979] 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]  

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

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. Useful Systems Agregados de Elementos Menores Base Utility Core Level Users

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)

Padrão Arquitetural: Camadas (3/4) Exemplo: Arquitetura em 3 Camadas para Sistemas de Informação. As requisições de serviços são feitas das Camadas mais externas para as mais internas. As respostas retornam no sentido contrário.

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

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.

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.

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.

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.

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.

EXEMPLOS DE PADRÕES

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.

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.

Singleton Estrutura: Singleton guarda a instância única static instance singletonData getInstance() singleton() singletonOperation() ponto de acesso único; retorna a instância o construtor é privado operações do Singleton

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

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

Singleton Contexto – exemplo de uso: Conseqüências: 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.

Singleton Exemplo: ControladorMatricula guarda a instância única ControladorMatricula instance = null - int passoCasoUsoMatricula dados do Singleton + ControladorMatricula getInstance() - ControladorMatricula() + boolean matriculaAluno() ponto de acesso único; retorna a instância o constru- tor é privado operações do Singleton

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

Singleton Exemplo: AcessoBD guarda a instância única AcessoBD instance = null conexao dados do Singleton + AcessoBD getInstance() - AcessoBD() + iniciarConexao() + encerrarConexao + incluirBanco(registro, tabela) + excluirBanco(chave, tabela) + consultarBanco (chave, tabela) operações do Singleton

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)

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.

Adapter (Padrão Estrutural) request() Client Target Adaptee request() specificRequest() Adapter Adaptee a a.specificRequest() request()

Participantes: Adapter 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.

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.

Adapter Contexto (exemplo): Ferramenta CASE Plug-in Adaptador O mesmo plug-in deve ser carregado em várias ferramentas CASE. Plug-in requisições Ferramenta CASE Adaptador requisições Oferece serviços necessários ao plug-in, mas cujas assinaturas ele desconhece.

Adapter Exemplo Aluno: Aluno GUIAluno Aluno a matricula() GUIAluno do sistema acadêmico da UFF. GUIAluno Aluno AdaptadorAluno requisições Aluno a matricula nome endereco requisições matricula() alterarSituacao() formarAluno() enturmar() a.matricularAluno() matricularAluno() trancarMatricula() cancelarMatricula() colarGrau() a.trancarMatricula() ou a.cancelarMatricula() Classe Aluno desenvolvida para o sistema acadêmico Do CEFET. a.colarGrau()

Adapter Vantagens: Desvantagens: 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.

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.

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

Diagrama de Estado do Objeto Matrícula

State Pattern – Contexto (Exemplo) As operações trancar, concluir etc, recebem o próprio objeto matricula como parâmetro. A operação setEstadomatricula recebe um objeto do tipo EstadoMatricula como 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).

State Pattern - Colaborações m1:Matricula estado:EstadoMatricula trancar() trancar() [trancou] setEstado(estadoConcreto = Trancada)

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

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

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.

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.

Exemplo: Aaa = 10 Bbb = 5,7 Cccc = 6,5 Ddd = 7,6

Observer - Estrutura * Subject Observer Herança Herança attach(Observer) detach(Observer) notify() update() For all observers -> o.update Herança Herança ConcreteSubject ConcreteObserver subjectState getState() setState() observerState update() -> observerState = subject.getState()

Observer - comportamento concreteSubject concreteObserver1 concreteObserver2 setState() notify() update() getState() update() getState()

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.

Observer Permite variar Subjects e Observers de forma independente. 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.