Padrões de Projeto. Prof. Jefersson Alex dos Santos

Transcrição

1 Padrões de Projeto Prof. Jefersson Alex dos Santos

2 Apresentação Conceitos Definição Ponto de vista prático História Padrões de Projeto Conhecidos Padrões GoF Outros Padrões Aplicações (JFC e SEAD) Conclusão

3 Conceitos Segundo o dicionário Aurélio: Padrão sm. 1. Modelo oficial de pesos e medidas. 2. O que serve de base ou norma para avaliação, medida. 3. Objeto que serve de modelo à feitura de outro. 4. Desenho decorativo estampado em tecido ou outra superfície.

4 Conceitos Para a Engenharia de Software: Um padrão é uma combinação recorrente de elementos de modelagem que ocorrem em algum contexto; Padrões podem ser aplicados nas diversas etapas do desenvolvimento de software.

5 Conceitos Fases de Desenvolvimento de Software: Ciclo de vida clássico

6 Padrões de Análise Um padrão de análise é qualquer parte de uma especificação de requisitos que se origina em um projeto e pode ser reutilizada em diversos projetos.

7 Padrões de Análise Exemplo: Padrão para reservas e locação de entidades reutilizáveis (quarto de hotel, aluguel de automóveis, filmes, etc).

8 Padrões de Projeto Os padrões de projeto são arquiteturas comprovadas para construir software orientado a objetos; A idéia é a mesma dos padrões de projeto aplicadas na arquitetura.

9 Padrões: Análise X Projeto Padrões de análise são dependentes da aplicação. Descrevem aspectos típicos de algum domínio ou aplicação; Padrões de projeto estão mais próximos da implementação. Focam interfaces, criação de objetos e propriedades estruturais.

10 Framework X Padrões Atenção: Padrões de Projeto e frameworks são coisas diferentes; Frameworks são estruturas de suporte bem definidas em que um outro projeto de software pode ser organizado e desenvolvido.

11 Ponto de Vista Prático Padrões de projeto não são algoritmos; Padrões de projeto não oferecem componentes; Padrões de projeto oferecem soluções comprovadamente eficientes; Catálogos de Padrões funcionam como Livros de Receitas.

12 Ponto de Vista Prático Software: Bolo de Chocolate

13 Ponto de Vista Prático Catálogos de Padrões de Projeto: Livros de Receitas

14 Ponto de Vista Prático Framework: Bolo de Caixinha

15 Design Patterns: FAQs Pra que serve? Por que utilizar? Compensa? Quais as vantagens? Quem deve utilizar? Como surgiram? Existem aplicações bem sucedidas?

16 Design Patterns: Vantagens Segundo Deitel & Deitel: Ajudam a construir software confiável com arquiteturas comprovadas; Promovem reutilização de projeto; Ajudam a identificar erros e armadilhas comuns; Estabelecem um vocabulário comum entre os desenvolvedores; Encurtam a fase de projeto.

17 Design Patterns: História Década de 1980: Linguagem OO: SmallTalk; C++ engatinhava ; Programação de Frameworks era bastante popular; Alguns frameworks, que hoje chamados de padrões, surgiram. Exemplo: MVC.

18 Design Patterns: História Década de 1990: Linguagens OO: C++, Java; Primeiras formalizações; Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides escreveram: Design Patterns: Elements of Reusable Object-Oriented Software The GoF Book.

19 Design Patterns: História Atualmente: Novos projetos são criados a todo momento; Há muitos projetos catalogados na Internet; Novos conceitos relacionam-se diretamente: XP (extreme Programming Programação Extrema); Refactoring (Refatoração).

20 Os Padrões GoF A turma dos quatro descreveu, em seu livro, 23 padrões de projeto; Esses padrões foram divididos em três categorias: Criacionais; Estruturais; Comportamentais.

21 Padrões de Criação Lidam com a melhor maneira de instanciar objetos; O aplicativo não deve depender de como os objetos são criados ou arranjados; Abstrair o processo de criação em uma classe criadora pode tornar o software mais flexível e genérico.

22 Padrões de Criação PADRÃO Abstract Factory Builder Factory Method Prototype Singleton DESCRIÇÃO É uma fábrica de objetos que retorna outras fábricas. Separa a construção de um objeto complexo de sua representação. Retorna uma instância dentre muitas possíveis classes, dependendo dos dados providos. Permite a um objeto devolver uma cópia de si mesmo para um objeto que o solicite. Garante que apenas uma única instância de uma classe vai existir.

23 Padrões Estruturais Descrevem maneiras comuns de organizar classes e objetos de um sistema: A herança pode ser utilizada para tornar mais utilizáveis as interfaces do programa; Objetos podem ser compostos em grandes estruturas utilizando composição ou inclusão de objetos dentro de outros.

24 Padrões Estruturais PADRÃO Adapter Bridge Composite DESCRIÇÃO Fornece um objeto de uma nova interface que se adapta à interface de outro objeto. Permite que se criem novos componentes para diferentes plataformas com uma ponte. A ponte esconde detalhes específicos de cada plataforma. Permite que um objeto cliente que está percorrendo uma estrutura hierárquica não precise determinar o tipo de cada componente dessa estrutura.

25 Padrões Estruturais (cont.) PADRÃO Decorator Facade Flyweight Proxy DESCRIÇÃO Permite que um objeto assuma responsabilidades adicionais dinamicamente. Permite que um objeto fachada forneça uma interface para os comportamentos de um subsistema. Permite reduzir o número de instâncias de um mesmo dado em uma classe. Permite que um objeto (Objeto Proxy) aja como um substituto para outro.

26 Padrões Comportamentais Oferecem estratégias comprovadas para modelar como os objetos colaboram uns com os outros em um sistema; Sugerem comportamentos especiais apropriados para uma grande variedade de aplicações.

27 Padrões Comportamentais PADRÃO Chain-of-Resp onsibility Command Interpreter Iterator DESCRIÇÃO Permite determinar o objeto que irá tratar uma mensagem em situações em que os objetos conversam. Permite especificar a funcionalidade desejada uma só vez, em um objeto reutilizável. Descreve como definir uma gramática e como utilizá-la para interpretar as entradas. Permite que objetos acessem dados individuais de qualquer estrutura de dados, sem conhecer o comportamento da estrutura de dados.

28 Padrões Comportamentais PADRÃO Mediator Memento Observer State DESCRIÇÃO Promove o baixo acoplamento entre duas classes fazendo com que as trocas de mensagens entre elas sejam realizadas por um objeto mediador. Permite que um sistema salve o estado de um objeto, podendo ser restaurado posteriormente. Permite que um mesmo objeto possua diversas representações. Perminte descrever comportamentos para estados que um objeto possui.

29 Padrões Comportamentais PADRÃO Strategy Template Method Visitor DESCRIÇÃO Permite armazenar um objeto estratégia que encapsula um algoritmo responsável pelo comportamento da classe. Exige que todos os objetos compartilhem um único algoritmo definido por uma superclasse. Permite que sejam adicionadas novas funcionalidades a classes existentes, de maneira plugável, sem que haja a necessidade de se alterar a hierarquia das classes.

30 Relacionamentos

31 Relacionamentos (Cont.)

32 Outros Padrões Padrões Arquiteturais; Padrões para Programação Paralela e Distribuída; Padrões J2EE;

33 Exemplos de Aplicação JFC (Java Foundation Classes): Swing: API Gráfica do Java; É considerada uma obra de arte da linguagem orientada a objetos. SEAD: Software Estatístico de Análise de Desempenho Acadêmico.

34 Conclusões Os padrões de projeto são maneiras convenientes de reusar código orientado a objetos entre projetos e programadores. A idéia é simples: catalogar interações comuns entre objetos que são utilizados freqüentemente pelos programadores.

35 Conclusões Termos relacionados: Programação Extrema (extreme Programming); Refatoração; Programação Orientada a Objetos. Não confundir com: Padrões de análise; Frameworks;

36 Referências Deitel, H. M. e Deitel, P. J. Java, Como Programar. Editora Bookman, 2003, 4ª edição, Porto Alegre, RS. Horstmann, Cay S. Cornell, Gary. Core Java 2 Volume I (Fundamentos). Editora Makron Books, 2001, São Paulo, SP. Cooper, James W. The Design Patterns: Java Companion. IBM Thomas J. Watson Research Center. Addison Wesley Design Patterns Series. Gamma, Helm, Johnson e Vlisside. Design Patterns: Elements of Reusable Software. Addison Wesley: 1995.