Padrões de Projeto These slides complement the E-book, Programming in the Large With Design Patterns available on both Kindle and Nook. Additional supporting.

Apresentação em tema: "Padrões de Projeto These slides complement the E-book, Programming in the Large With Design Patterns available on both Kindle and Nook. Additional supporting."— Transcrição da apresentação:

1 Padrões de Projeto These slides complement the E-book, Programming in the Large With Design Patterns available on both Kindle and Nook. Additional supporting material is available at A note to the presenter: this presentation is adaptable for different audiences. Delete or hide the slides you don’t feel are relevant for your particular audience. 1

2 Apresentação sobre Padrões de Projeto traduzida e adaptada do livro:
This presentation introduces design patterns. For the details, buy the book at amazon.com or 2

3 Sumário Um simples exemplo História dos padrões de projeto
O que é um padrão de projeto de software? Código  Projeto  Padrão de Projeto Categorias de padrões Nem todos os pares problema-solução são padrões Benefícios dos padrões de projeto Questão resolvida Modelos de padrão de projeto Padrões de Projeto Singleton, Iterator, Observer, e outros Intent matters - different design patterns can have similar or even identical structure. These patterns are distinguished by intent. (Sections on design concepts and intent can be skipped without loss of continuity. Both sections are more relevant when looking at the details of design patterns. Even then it may make more sense to discuss a few design patterns in detail before covering these sections. The issues they address are easier to relate to once a few design patterns have been studied in detail.) 3

4 Projeto de SIG p/ Biblioteca
Imagine que você está na etapa final do projeto de um SIG para uma biblioteca. Os requisitos solicitados permitem aos usuários: Pegar um livro (empréstimo) Devolver um livro Renovar um livro, e Reservar um livro

5 Diagrama de Caso de Uso do SIG p/ Biblioteca
Pegar Livro Devolver Livro Renovar Livro Usuário da Biblioteca Reservar Livro

6 Rascunho do Projeto Q. Any problems?
A. No major ones, but it could lead to high coupling. The main features (shown in bold) are distributed over three classes. The user interface (UI) subsystem that will make use of these classes will have dependencies on all three classes. The coupling between the UI subsystem and core logic could be reduced if all features were accessible from a single component. 6

7 O que fazer? Alto Acoplamento
Q. In general, how would you approach this “problem” of a sub-optimal design? A. If you fancy yourself an engineer, your first inclination should be to look for a routine or existing design solution before resorting to original design. For software engineers this means consulting handbooks on design patterns. 7

8 Livros sobre projeto de software oferecem soluções reutilizáveis ​​para problemas recorrentes de projeto The top handbooks on software design offer brief summaries of reusable design solutions. Singleton – O padrão de projeto Singleton garante que não mais do que uma instância de uma classe seja criada. . . 8

9 Procurando por uma solução para o nosso problema de projeto de software
Iterator – O padrão de projeto Iterator fornece uma maneira uniforme de examinar. . . Façade – A intenção do padrão de projeto Façade é “prover uma interface unificada para um conjunto de interfaces em um subsistema. Façade define um alto nível de interface que torna o subsistema mais fácil de ser usado.” [Gang of Four] Façade seems to be a good match for the problem at hand. The full write-up for the pattern provides guidelines for applying the pattern in different contexts. 9

10 Resultado do projeto após a aplicação do padrão de projeto Façade
In this example, high coupling signaled a weakness in the design, which was then remedied with the Façade design pattern. Design will always involve some level of creativity and innovation but skillful application of design principles and patterns can help make the process a little more routine. 10

11 O novo projeto realmente é melhor?
A nova classe Façade tem as mesmas três setas presentes no projeto antigo? O novo projeto também não tem um alto acoplamento? Answer: the new design has lower coupling. The user interface (UI) component represents many classes. In the old design there were potentially many references from the UI classes to the business logic classes (Book, BookCopy and Patron). In the new design the UI classes deal only with the façade class. The UI classes went from having dependencies on three classes each with their own moderately complex interface to having a dependency on just one class with a simple interface. 11

12 História dos Padrões de Projeto
Padrões não tiveram origem com software; surgiram na esfera do planejamento urbano e arquitetura. Na década de 70, Christopher Alexander propôs a criação de um padrão de estilo que as pessoas comuns pudessem usar para criar edifícios ​​e espaços públicos mais agradáveis.. O primeiro livro sobre padrões, A Pattern Language: Towns, Buildings, Construction, documentou 253 padrões. Cada padrão provia uma solução geral para um problema de projeto recorrente em um contexto particular. Each pattern in the book describes a solution to a problem in a context. Design patterns first appeared in A Pattern Language: Towns, Buildings, Construction, by Christopher Alexander. The book contains 253 patters for creating livable buildings and public spaces. 12

13 História dos padrões de projeto de software
Em 1987 Kent Beck e Ward Cunningham proporam a criação de um estilo padrão para projetos de software. Sua visão original era permirtir que os usários “escrevessem seus próprios programas”. “Nosso sucesso inicial utilizando um estilo padrão para o projeto de interface de usuário nos deixou bastante entusiasmado com as possibilidades de usuários de computador projetarem e programarem seus próprios aplicativos.” [Sowizral] Ten years after the publication of Christopher Alexander’s book on architecture patterns, Kent Beck and Ward Cunningham proposed creating a pattern language for software design analogous to Christopher Alexander’s pattern language for town and building design [OOPSLA-87]. 13

14 Gangue dos Quatro O movimento de padrões de software começou para valer após a publicação de Design Patterns: Elements of Reusable Object-Oriented Software [1994]. Os quatro autores Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides são conhecidos coletivamente como a “Gang of Four” or GofF (Gangue dos Quatro).

15 Marcos importantes na história dos padrões de projeto
1977 Cristopher Alexander co-autor do primeiro livro sobre padrões, A Pattern Language: Towns, Buildings, Construction, documentou 253 padrões em planejamento urbano e arquitetura de construções. 1994 A gangue dos quatro iniciaram o movimento de padrões de software com a publicação do primeiro livro de padrões de software: Design Patterns: Elements of Reusable Object-Oriented Software. O livro documenta 23 padrões de projeto de software. 1987 Kent Beck e Ward Cunningham proporam a criação de um estilo padrão para projetos de software a luz das ideias do estilo padrão para projetos urbanos e construções de Christopher Alexander Marcos importantes na história dos padrões de projeto

16 O que é um padrão de projeto?
Um padrão de projeto de software é uma solução reusável para um problema de projeto recorrente. A proposta do processo de design é determinar como eventuais códigos serão estruturadas ou organizados em módulos. A saída do processo de design é um modelo abstrato de solução tipicamente expressada por meio de uma linguagem simbólica de modelagem, como UML. A design pattern is not a concrete design or implementation (such as an algorithm) that can be used as-is, but rather a generic solution that is adapted to the specific needs of the design problem at hand. 16

17 Padrões de Projeto como Problema → Pares de Soluções
Conceitualmente, um padrão de projeto provê um mapeamento de um problema específico de design para uma solução genérica. Problema de Design Solução Genérica Como posso garantir que uma classe só tenha uma instância? Design patterns offer reusable solutions to midlevel design problems. Handbooks of design patterns offer ready-made solutions to the most common design problems. Conceptually, a design pattern is a mapping that provides a general solution to a specific design problem Como posso fazer objetos dependentes cientes das mudanças de estado em um objeto subordinado sem o uso de votação? 17

18 Padrões de Projeto Definidos
Conhecimento de padrões de projeto simplifica o projeto do software pela redução do número de problemas de design que são resolvidos a partir de princípios fundamentais. Problemas de projeto que correspondem a padrões de projeto documentados, têm soluções prontas. Os demais problemas que não correspondem a padrões de projeto documentados devem ser resolvidos a partir de princípios fundamentais. 18

19 Código  Projeto  Padrão de Projeto
A seguir, o código será familiar a qualquer um que tenha escrito um programa GUI em Java: 19

20 Código  Projeto  Padrão de Projeto
Da mesma forma, o seguinte código será familiar a qualquer um que tenha escrito um programa GUI em C #: Click is an event of type EventHandler declared in the Button class. 20

21 Código  Projeto  Padrão de Projeto
Em cada caso, um manipulador de eventos ou de rotina callback é registrado para lidar com eventos de clique de botão. Cada implementação é única, mas em ambos os casos o projeto é o mesmo. Two implementations for the same design 21

22 Código  Projeto  Padrão de Projeto
Em ambos os casos, o problema de projeto geral é como permitir que um ou mais objetos (aqueles que contêm as rotinas de tratamento de eventos) possa ser notificado quando o estado de outro objeto (o botão) muda. Este é um problema de design rotineiro para o qual existe uma solução reutilizável na forma do padrão de projeto Observer. 22

23 Padrão de Projeto Observer
Nome do Padrão: Observer. Contexto: Um ou mais objetos (observadores) precida saber das mudanças de estado em outro objeto (o sujeito). Problema: Os objetos que fazem a observação (observadores) deve estar dissociados do objeto sob observação (o sujeito). Solução: Definir uma classe ou interface Subject (Sujeito) com métodos para vincular e desvincular os observadores, bem como um método para notificar aos observadores vinculados quando o estado do sujeito muda. Definir uma interface Observer que define um método de retorno que sujeitos podem usar para notificar os observadores de uma mudança.

24 Padrão de Projeto Observer [Cont.]
Modelo de solução abstrada para o padrão de projeto Observer: Because natural language is not well-suited to conveying design ideas, design patterns are often expressed using a visual modeling language such as UML. The following UML diagram shows the abstract solution model for the Observer design pattern. 24

25 Categorias de Padrões As quatro categorias principais de padrões de software são: padrões de análise, padrões de arquitetura, padrões de projeto e idiomas de programação. It is hard to keep a good idea from spreading. The use of patterns has branched out from design to find application in other stages of the software life cycle. Software patterns can be classified according to development stage during which they are used: analysis, design and implementation. Patterns of design can further be distinguished by level of abstraction: high-level and mid-level. 25

26 Padrões de Análise Pessoa Padrões de análise documentam conhecimento coletivo de abstrações comumente encontradas durante a análise de domínio e modelagem de negócios. Física Jurídica Exemplo de padrão de análise: Party (Pessoa). O padrão de análise Party é uma abstração que representa uma pessoa (Física) ou organização (Jurídica). The best reference for analysis patterns is Martin Fowler's book, Analysis Patterns [Fowler 1997]. It documents 76 analysis patterns including Party and other familiar domain concepts such as Account, Contract, Product, Measurement and Quantity. 26

27 Padrões de Arquitetura
Projeto ocorre em diferentes níveis. Um padrão de arquitetura é um plano de alto nível para organizar os componentes de nível superior de um sistema de programa ou software. Well-known architecture patterns (or styles) include: client-server, n-tiered, blackboard, and model-view controller [Buschmann et al. 1996] [Shaw and Garlan, 1996]. 27

28 Padrões de Projeto Os padrões de projeto resolvem os problemas de projeto de nível médio. As soluções para estes problemas são definidos por um pequeno número de classes e/ou objetos. Padrões de projeto são o assunto desta apresentação. 28

29 Idiomas de Programação
Um idioma de programação é um padrão de baixo nível, de linguagem específica que explica como realizar uma tarefa simples, usando uma linguagem de programação específica ou tecnologia. Um termo mais popular para idioma de programação hoje é a receita... Exemplo Problema: Como garantir que instâncias de uma classe C + + nunca sejam copiadas? Solução: Declare a cópia do construtor e copia do operador de atribuição da classe como privado e não implemente-as. Just about every major programming language and platform technology has at least one "cookbook" of recipes for how to accomplish specific tasks using the language or platform [Python Cookbook] [Arduino Cookbook] [Rails Recipes]. 29

30 Nem todos os pares problema-solução são Padrões
Embora não haja critérios formais ou teste decisivo para o que é e não é um padrão, existem alguns pares problema-solução que não são geralmente consideradas como padrões. 30

31 Algoritmos não são padrões de projeto
Algoritmos não são padrões de projeto, porque eles têm objetivos diferentes. A finalidade de um algoritmo é resolver um problema específico (triagem, pesquisa, etc) de uma maneira computacionalmente eficiente, como medido em termos de tempo e de espaço de complexidade. O objetivo de um padrão de projeto é organizar o código de uma maneira eficiente medida em termos de flexibilidade, facilidade de manutenção, reutilização, etc

32 Designs únicos não são padrões
Nem todos os projetos de software sobe para o nível de um padrão. Padrões são frequentemente descritos como soluções reutilizáveis ​​e bem comprovada. Você não pode ter certeza se um projeto único é reutilizável ou comprovado. A métrica geral é que um projeto de software não pode ser considerado um padrão até que tenha sido aplicado em uma solução do mundo real pelo menos três vezes (a chamada "Regra de Três"). This is why many say that design patterns are discovered rather than invented. 32

33 Benefícios dos Padrões de Projeto
Padrões de Projeto facilitam o reuso. Padrões de Projeto deixam o projeto mais fácil, mas não é fácil. Padrões de Projeto captura conhecimento e facilita sua difusão. Padrões de Projeto define um vocabulário comum para a discussão de projeto. Padrões de Projeto move o desenvolvimento de software para mais próximo de uma disciplina de engenharia bem estabelecida. Padrões de Projeto demonstra conceitos e princípios de bom design. Conhecer padrões de projeto populares torna mais fácil de aprender bibliotecas de classe que usam padrões de projeto. 33

34 Ponto Importante Faça o teste de comparação imparcial dos padrões de projeto. Você pode dizer qual dos seguintes diagramas de classe representam o State e qual representa o Strategy?

35 State vs. Strategy É claro que é impossível dizer qual é o State e qual é o Stratey. Estruturalmente eles são idênticos. Os padrões de projeto não se distinguem só pela sua estrutura estática. O que torna um padrão de design único é o seu objetivo.

36 Objetivo O objetivo de um padrão é o problema a ser resolvido ou a razão para usá-lo. A intenção do padrão de State é permitir que um objeto altere seu comportamento quando seu estado interno muda. A intenção do padrão Strategy é encapsular diferentes algoritmos ou comportamentos e torná-los intercambiáveis ​​partir da perspectiva do cliente. Why have two different patterns if their static structure is the same? Recall that design patterns do more than just tell you how to organize the code. They also communicate information about the problem being solved. Consider this: designs are typically communicated using a class and sequence diagram. The sequence diagram shows typical dynamic behavior. While design patterns aren’t distinguished by their static structure, in all cases I can think of they are distinguished by their typical dynamic behavior. One piece of information communicated by a pattern name is typical dynamic behavior (i.e. sequence diagram). 36

37 Modelos de Padrões de Projeto
Padrões de projeto são quase sempre apresentados utilizando uma estrutura uniforme. Ter um formato consistente faz com que seja mais fácil de aprender, comparar e usar padrões.

38 Modelo Exemplo Nome do Padrão – um nome descritivo curto.
Introdução – motivação para aprender o padrão Objetivo – o problema de projeto que o padrão aborda. Solução – os aspectos comportamentais estruturais estáticos e dinâmicos da solução. Código de Exemplo – um fragmento de código mostra um exemplo de implementação do padrão. Discussão – alguma das questões de implementação relacionadas com a utilização do padrão. Padrões relacionados – padrões relacionados com o que está sendo descrito. Probably the most important section is “Intent”. It is the trigger for recognizing when there is an opportunity to use the design pattern. If you don’t know a solution exists, you very well could find yourself reinventing the wheel. 38

39 Padrões de Projeto Singleton Iterator Adapter Decorator State Strategy
Factory Method Observer Façade Template Method

40 Singleton Objetivo – O padrão de projeto Singleton garante que não mais do que uma instância de uma classe seja criada e fornece um ponto global de acesso a essa instância.

41 Solução 41

42 Iterator Objetivo – O padrão de projeto Iterator fornece uma maneira uniforme de percorrer os elementos de uma coleção de objetos.

43 Solution 43

44 Adapter Objetivo – O padrão de projeto Adapter é útil em situações em que uma classe existente fornece um serviço necessário, mas há uma incompatibilidade entre a interface oferecida e o que os clientes da interface esperam. O padrão Adapter mostra como converter a interface da classe existente na interface esperada pelos clientes.

45 Solução usando composição
There are two different ways of implementing the Adapter design pattern, one using composition and the other using inheritance. Solução usando composição 45

46 Solução usando herança
46

47 Decorator Objetivo – O padrão de projeto decorator fornece uma maneira de anexar dinamicamente responsabilidades adicionais a um objeto. Ele usa a composição de objetos ao invés de herança de classe para uma abordagem leve e flexível ao adicionar responsabilidades a objetos em tempo de execução.

48 Solução – Estrutura estática
48

49 Decorators wrap concrete components (or other decorators)
Decorators wrap concrete components (or other decorators). Operations on decorators add behavior before or after calling operations on decorated components. Diagrama Conceitual 49

50 Solução – Comportamento Dinâmico
50

51 State Objetivo – Se um objeto passa por estados claramente identificáveis, e o comportamento do objeto é especialmente dependente de seu estado, ele é um bom candidato para o padrão de projeto State.

52 Solução 52

53 Strategy Objetivo – O padrão de projeto Strategy define uma família de algoritmos, encapsula cada um, e os torna intercambiáveis. Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam. [Gang of Four].

54 Solução 54

55 Factory Method Intent – O padrão Factory Method "define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe instanciar. Factory Method permite que uma classe submeta a instanciação para subclasses." [Gang of Four]

56 Solução 56

57 Observer Objetivo – O padrão de projeto Observer define uma relação um-para-muitos entre um objeto sujeito e qualquer número de objetos observadores de tal forma que, quando o objeto sujeito muda, objetos observadores são notificados e dada a chance de reagir a mudanças no sujeito.

58 Solução – Estrutura Estática
58

59 Solução – Comportamento Dinâmico
59

60 Solução com classe base comum para sujeitos
Logic in the subject for attaching, detaching and notifying observers is the same for all subjects. One way to avoid repeating this logic in different subjects is to encapsulate the logic in a separate reusable class Subject that is inherited by all concrete subjects. Solução com classe base comum para sujeitos 60

61 Façade Objetivo – O objetivo do padrão de projeto Façade design é “prover uma interface unificada para um conjunto de interfaces em um subsistema. Façade define uma interface de alto- nível que torna o subsistema mais fácil de usar.” [Gang of Four]

62 Solução 62

63 Template Method Objetivo – Com o padrão de projeto Template Method a estrutura de um algorítmo é representada com variações sobre o algorítmo implementado pelas subclasses. O esqueleto do algoritmo é declarado em um método modelo em termos de operações substituíveis. As subclasses podem estender ou substituir algumas ou todas destas operações.

64 Solução 64

65 Fim

66 Motivação Na maioria das empresas, a mais importante posição técnica e que tem a maior remuneração e prestígio é o do designer ou arquiteto. Uma opção para adquirir o conhecimento necessário para ser um designer eficaz é passar anos trabalhando como designer ou como um aprendiz de um designer. Aprender com a experiência em primeira mão é demorado. Pode se levar uma quantidade razoável de tempo para experimentar uma grande variedade de problemas e ainda mais tempo para aprender quais as soluções que funcionam e quais não funcionam. Outra rota mais eficiente para se tornar um designer especializado é estudar padrões de projeto. Os padrões de design capturam conhecimento especializado em um formato que facilita a aprendizagem e reutilização. Estudar catálogos de padrões de projeto pode reduzir significativamente o tempo que leva para se tornar um designer qualificado ou arquiteto. [When speaking to developers still in school or just starting their career I sometimes include this slide at the beginning of the presentation.] At most companies, the senior-most technical position—the one with the most pay and prestige—is that of designer or architect. This is understandable considering the huge impact design decisions have over the life of a software system. Good designs make software easier to develop, maintain and evolve. Bad designs increase development costs and risks—possibly to the point that nontrivial changes to the code become impossible. The difference between good and bad design over the life of a product can be dramatic. One option for acquiring the expertise needed to be an effective designer is to spend years working as a designer or as an apprentice to a designer. Learning from first-hand experience is time-consuming. It takes many years to experience a broad range of design solutions and even longer to understand the different contexts in which they do and don’t work. Another more efficient route to becoming a skilled designer is to study design patterns. Design patterns capture expert knowledge in a format that facilitates learning and reuse. Studying catalogs of design patterns can significantly shorten the time it takes to become a skilled designer or architect. 66

67 Low Sill (Soleira Baixa)
Para se ter uma ideia de como os padrões em geral funcionam, considere uma Low Sill, um padrão na construção civil usado para determinar a altura de uma janela. Photo credit: Searl Lamaster Howe Architects I sometimes include this slide and the next 2 when discussing the history of design patterns. This slide and the next 2 can be inserted after slide 12 in this presentation. 67

68 Padrão Low Sill Aqui está um resumo do padrão na forma padrão:
Contexto: Janelas estão sendo planejadas para a parede. Problema: Quão alto deve ser o parapeito da janela ao chão? A janela que é muito alta corta você de fora do mundo exterior. Uma que seja muito baixa poderia ser confundido com uma porta ou uma parede e é potencialmente inseguro. Solução: Projete o parapeito da janela para ser de 12 a 14 centímetros do chão. Nos pisos superiores, para a segurança, torná-los mais elevado, em torno de 20 polegadas. A principal função de uma janela é conectar os ocupantes do edifício ao mundo exterior. A ligação é mais significativa quando ambos, o chão e o horizonte são visíveis quando de pé se está distante um ou dois pés da janela. 68

69 Low Sill [Cont.] Este exemplo ilustra um par de características importantes de padrões. Projeto (e mais geralmente de engenharia) é sobre equilibrar as forças conflitantes ou restrições. Padrões de projeto fornecem soluções gerais em um nível médio de abstração. Padrões não são dogmas. This example illustrates a couple of important characteristics of patterns. First, design (and more generally engineering) is about balancing conflicting forces or constraints. Here the objective is to make the windowsill low enough to see the ground in order to make a connection with the outside world but high enough to be safe and not to be confused with a door. Second, design patterns provide general solutions at a medium level of abstraction. They don't give exact answers (precise measurements in the case of Low Sill), and at the same time, they are more concrete and practical than abstract principles or strategies. In the example above, the solution is given in terms of a range of heights: 12 to 20 inches. How high to set a window will depend on preferences and local conditions. The optimal height is the value that best balances the conflicting forces. Finally, patterns aren't dogma. The pattern doesn't say that all windowsills must be 12 to 20 inches off the floor. If you are designing a jail cell, for example, there may be overriding factors that call for a windowsill height outside of the recommended 12 to 20 inches. 69