A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Padrões de Projeto para Software Orientado a Objetos Professora: Aline Vasconcelos IF-Fluminense"— Transcrição da apresentação:

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

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

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

8 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 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 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 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 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 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 14 EXEMPLOS DE PADRÕES

15 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 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 17 Singleton Estrutura: Singleton getInstance() singleton() singletonOperation() ponto de acesso único; retorna a instância o construtor é privado operações do Singleton static instance singletonData guarda a instância única

18 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 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 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 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 única dados do Singleton

22 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 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 única dados do Singleton

24 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 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 26 Adapter (Padrão Estrutural) Estrutura: Client Adaptee specificRequest() Target request() Adaptee a Adapter request() a.specificRequest() request()

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

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

31 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 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 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:

34 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 35 Diagrama de Estado do Objeto Matrícula

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

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

38 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 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 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 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 42 Exemplo: Aaa = 10 Bbb = 5,7 Cccc = 6,5 Ddd = 7,6

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

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

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


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

Apresentações semelhantes


Anúncios Google