Transferir como PDF, PPTX
Carregado porFabio Moura Pereira
Padrões de Projeto de Software
O documento discute padrões de projeto de software. Apresenta uma introdução sobre o que são padrões de projeto e sua motivação. Também descreve conceitos básicos como atributos, problemas resolvidos e tipos de padrões.
Mais conteúdo relacionado
Semelhante a Padrões de Projeto de Software
![[CEFETMG][ESw] Aula 6 - Conceitos de projeto](https://cdn.slidesharecdn.com/ss_thumbnails/aula6-conceitosdeprojeto-150616154700-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
Padrões de Projeto de Software
- 1. Padrões de Projetode Software Algoritmos e Programação II Fábio M. Pereira
- 2. Roteiro Introdução: ◦Oque são padrões de projeto? ◦Motivação Conceitos básicos: ◦Atributos ◦Problemas ◦Seleção ◦Uso Tipos Exemplos
- 3. Introdução Engenharia deSoftware trata: ◦Metodologia para desenvolvimento de sistemas ◦Linguagem de Modelagem para o projeto de software Dificuldades: ◦Falta de experiência ◦Dificuldade de combinação de todos os elementos “Estudos de Casos” são uma fonte bastante rica para a solução de problemas de projeto, mesmo para projetistas experientes
- 4. Padrões de projetode SW Padrões de Projeto de Software ou Design Patterns descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos ◦Pelo fato de ser recorrente, vale a pena que seja estudada e documentada Os padrões de projeto visam facilitar a reutilização de soluções na fase de projeto do software Também resultam em um vocabulário comum de projeto, facilitando comunicação, documentação e aprendizado dos sistemas de software O que faz um padrão de projeto? ◦Nomeia, abstrai e identifica os aspectos-chave de uma estrutura de projeto comum para torná-la útil para a criação de um projeto orientado a objetos reutilizável
- 5. Outras vantagens Aumentoda comunicação entre times e aprendizagem individual Aumento da capacidade de modificação e de manutenção de código Aumento do entendimento de princípios de projeto básicos em orientação a objetos (encapsulamento, herança e polimorfismo) Adoção de estratégias melhores mesmo quando padrões não estão presentes Aprendizado de melhores alternativas para problemas complexos, principalmente aqueles com grandes hierarquias
- 6. Problemas solucionados porpadrões Procurando objetos apropriados Determinando a granularidade dos objetos Especificando interfaces dos objetos Especificando implementações dos objetos ◦Herança de classe versus herança de interface ◦Programando para uma interface, não para uma implementação Colocando os mecanismos de reutilização para funcionar ◦Herança versus composição ◦Delegação ◦Herança versus tipos parametrizados
- 7. Problemas solucionados porpadrões Relacionando estruturas de tempo de execução e de tempo de compilação Projetando para mudanças Dependências de operações específicas, plataformas de software e hardware, de representações ou implementações de objetos e algorítmicas Acoplamento forte Incapacidade na alteração de classes ◦Programas de aplicações ◦Bibliotecas de classes (toolkits) ◦Conjuntos de classes (frameworks)
- 8. Atributos Nome ◦Referênciaque descreve de forma bastante sucinta o padrão Problema ◦Motivação, intenção e objetivos, aplicabilidade ◦Apresenta o contexto do padrão e quando ele pode ser usado Solução ◦Estrutura, participantes, exemplo de código ◦Descreve a solução e os elementos que a compõem Consequências e padrões relacionados ◦Analisa os resultados, vantagens e desvantagens obtidos com a aplicação do padrão
- 9. Como selecionar umpadrão de projeto? Considere como os padrões de projeto solucionam problemas de projeto Examine as seções de descrição do problema de cada padrão Estude como os padrões se inter-relacionam Estude padrões de finalidades semelhantes Examine uma causa de reformulação de projeto Considere o que deveria ser variável no seu projeto
- 10. Como usar umpadrão de projeto? Leia o padrão por inteiro, uma vez, para obter uma visão geral Estude as seções de descrição do problema e do padrão Olhe exemplos de código do padrão Escolha nomes para os participantes do padrão que tenham sentido no contexto da aplicação Defina as classes Defina nomes específicos da aplicação para operações no padrão Implemente as operações para suportar as responsabilidades e colaborações presentes
- 11. Tipos de padrõesde projeto Em geral os padrões de projeto podem ser classificados em três diferentes tipos: ◦Padrões de criação Abstraem o processo de criação de objetos a partir da instanciação de classes Abstract Factory, Factory Method, Sigleton, Builder, Prototype ◦Padrões estruturais Tratam da forma como classes e objetos estão organizados para a formação de estruturas maiores Adaptor, Decorator, Proxy, Bridge, Facade, Composite, Flyweight ◦Padrões comportamentais Preocupam-se com algoritmos e a atribuição de responsabilidades entre objetos Chain of Responsibility, Mediator, Strategy, Command, Memento, Template Method, Interpreter, Observer, Visitor, Iterator, State
- 12. Tipos de padrõesde projeto Podem ser subclassificados em: ◦Padrões de classes Em geral estáticos, definidos em tempo de compilação ◦Padrões de objetos Em geral dinâmicos, definidos em tempo de execução
- 13. Padrões GoF (Gangof Four) Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0- 201-63361-2) is a software engineering book describing recurring solutions to common problems in software design. The book's authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch. They are often referred to as the Gang of Four, or GoF. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk. It won a Jolt productivity award, and Software Development productivity award in 1994. The original publication date of the book was October 21, 1994 with a 1995 copyright, and as of April 2007, the book was in its 36th printing. The book was first made available to the public at OOPSLA meeting held in Portland, Oregon in October 1994. It has been highly influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice. More than 500,000 copies have been sold in English and in 13 other languages. Wikipedia
- 14. Padrões de Projetode Criação - Abstract Factory - Builder - Factory Method - Prototype - Singleton
- 15. Abstract Factory Forneceuma interface para a criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas Algumas vezes vários objetos precisam ser instanciados em uma maneira coordenada Por exemplo, ◦Quando lidamos com interfaces do usuário, o sistema pode precisar usar um conjunto de objetos para trabalhar em um sistema operacional e um outro conjunto de objetos para trabalhar em um sistema operacional diferente ◦Transportabilidade entre diferentes sistemas de interfaces gráficas (Windows, Motif, MacOS)
- 16.
- 17. Builder Separa aconstrução (geralmente passo a passo) de um objeto complexo da sua representação, de modo que o mesmo processo de construção possa criar diferentes representações Permite que um objeto cliente construa um objeto complexo especificando apenas o seu tipo e o seu conteúdo ◦O cliente é blindado dos detalhes da construção do objeto Exemplos: ◦O problema de construir um programa que realize gateway para e-mails O programa recebe mensagens que estão no formato MIME 3 e encaminha as mensagens para diferentes tipos de sistemas de e-mail ◦Conversão de formatos de texto em editores
- 18. MessageBuilder is anabstract builder class. It defines methods that correspond to the various header fields and body types that MIME supports. It declares abstract methods that correspond to required header fields and the most common body types. It declares these methods abstract because all concrete subclasses of MessageBuilder should define these methods. However, some of the optional header fields such as organization and fancier body types such as Image/Jpeg may not be supported in all message formats, so the MessageBuilder class provides do-nothing implementations of these methods.
- 19. The MessageBuilder classalso defines a class method called getInstance. A MIMEParser object passes the get Instance method the destination address of the message it is parsing. From the message's destination address, the getInstance method determines the message format needed for the new message. It returns an instance of the subclass of Message-Builder appropriate for the format of the new message to the MIMEParser object. The MAPIBuilder and PROFSBuilder classes are concrete builder classes for building Messaging Application Programming Interface (MAPI) and PROFS (a registered trademark of the IBM corporation) messages, respectively. The builder classes create product objects that implement the OutboundMsgIF interface. This interface defines a method called send that is intended to send the e-mail message wherever it is supposed to go. 1.A MessageManager object receives an e-mail message. 1.1 The MessageManager object calls the MIMEParser class's parse method. It will return an OutboundMessageIF object that encapsulates the new message in the needed format. 1.1.1 The MIMEParser object calls the MessageBuilder class's getInstance method, passing it the destination email address. By analyzing the address, the method selects a concrete subclass of the MessageBuilder class and creates an instance of it. 1.1.2 The MIMEParser object passes the destination email address to the MessageBuilder object's to method. 1.1.3 The MIMEParser object passes the originating email address to the MessageBuilder object's from method. 1.1.4 The MIMEParser object passes the email message's simple content to object's plainText method. 1.1.5 The MIMEParser object passes the email message's attached jpeg image to the MessageBuilder object's jpegImage method. 1.1.6 calls MessageBuilder object's getOutboundMsg method to complete and fetch the new message. 1.2 The MessageManager object calls the OutboundMsg object's send method. This sends the message off and completes the message processing.
- 20. Factory Method Defineuma interface para criar um objeto, mas deixa as subclasses decidirem qual classe será instanciada Permite a uma classe postergar a instanciação de subclasses Bastante utilizado em toolkits e frameworks para a instanciação de objetos
- 21. Factory Method ProductIF.The objects created using this pattern must implement an interface in this role. ConcreteProduct1, ConcreteProduct2, and so on. Classes in this role are instantiated by a Factory object. Classes in this role must implement the ProductIF interface. CreationRequester. A class in this role is an application-independent class that needs to create application-specific classes. It does so indirectly through an instance of a class that implements the FactoryIF interface. FactoryIF. This is an application- independent interface. Objects that create ProductIF objects on behalf of CreationRequester objects must implement this interface. Interfaces of this sort declare a method that can be called by a CreationRequester object to create concrete product objects. The arguments this method takes are discussed under the Implementation section for this pattern. Interfaces filling this role will typically have a name that includes the word Factory, such as DocumentFactoryIF or ImageFactoryIF. Factory. This is an application-specific class that implements the appropriate FactoryIF interface and has a method to create ConcreteProduct objects. Classes filling this role will typically have a name, such as DocumentFactory or ImageFactory, that contains the word Factory.
- 22. Factory Method Sem Factory Method
- 23. Prototype Especifica ostipos de objetos a serem criados usando uma instância como protótipo e cria novos objetos copiando este protótipo Permite que um objeto crie objetos customizados sem conhecer a sua classe exata ou os detalhes de como eles serão criados ◦Objetos a serem utilizados como protótipos devem possuir um método (clone) que retorna um novo objeto que é uma cópia do objeto original Exemplo: ◦Criação de objetos de desenho CAD a partir de protótipos previamente criados
- 24. Prototype. Classes inthis role implement the PrototypeIF interface and are instantiated for the purpose of being cloned by the client. Classes in this role are commonly abstract classes with a number of concrete subclasses. PrototypeIF. All prototype objects must implement the interface that is in this role. The client class interacts with prototype objects through this interface. Interfaces in this role should extend the Cloneable interface so that all objects that implement the interface can be cloned. PrototypeBuilder. This corresponds to any class instantiated to supply prototypical objects to the client object. Such classes should have a name that denotes the type of prototypical object that they build, such as SymbolBuilder. A PrototypeBuilder object creates Prototype objects. It passes each newly created Prototype object to a Client object's registerPrototype method. Client. The client class represents the rest of the program for the purposes of the Prototype pattern. The client class needs to create objects that it knows little about. Client classes will have a method that can be called to add a prototypical object to a client object's collection. In Figure 5.14, this method is indicated with the name registerPrototype. However, a name that reflects the sort of object being prototyped, such as registerSymbol, is more appropriate in an actual implementation.
- 26. O padrão Singleton Objetivo ◦Queremos apenas uma instância de um objeto, mas não existe um objeto global que controla a instanciação deste objeto ◦Queremos também garantir que todas as entidades estão usando a mesma instância deste objeto Problema ◦Vários objeto clientes diferentes precisam referenciar a mesma coisa, e queremos garantir que não exista mais que uma dela Solução ◦Garantir uma única instância Consequências ◦Clientes não precisam se preocupar se uma instância do Singleton existe pois o controle é feito internamente Implementação ◦Adicione um membro estático privado da classe que referencia o objeto desejado (inicialmente = null) ◦Adicione um método estático público que instancia esta classe se este membro é null (e atribui o valor do membro) e retorna o valor do membro ◦Adicione o estado do construtor para privado ou protegido de maneira que ninguém poderá instanciar a classe diretamente e sobrepor o mecanismo do construtor estático
- 27. Estrutura genérica dopadrão Singleton / Exemplo Java Singleton - static instance - singleton Data + static getInstance() + SingletonOperation() + getSingletonData() Return instance public class USTax extends Tax { private static USTax instance; private USTax() { } public static USTax getInstance() { if (instance== null) instance= new USTax(); return instance; } }
- 28. Padrões de ProjetoEstruturais - Adapter - Bridge - Composite - Decorator - Façade - Flyweight - Proxy
- 29. Adapter Converte ainterface de uma classe em outra interface esperada pelos clientes Permite que certas classes trabalhem em conjunto, pois de outra forma seria impossível por causa de suas interfaces incompatíveis Exemplo: ◦Wrapper – usado para adaptar a interface de classes
- 30.
- 31. Supondo que eutenha: E queira adicionar... Utilizando Adapter (reuso da classe XXCircle)
- 32. Bridge Separa umaabstração da sua implementação, de modo que as duas possam variar independentemente
- 33. Composite Compõe objetosem estrutura de árvore para representar hierarquias do tipo partes-todo Permite que os clientes da estrutura tratem objetos individuais e composições de objetos de maneira uniforme
- 34.
- 35. Decorator Atribui responsabilidadesadicionais a um objeto dinamicamente Fornece uma alternativa flexível à utilização de subclasses para a extensão de funcionalidades Permite a criação de uma cadeia de objetos que iniciam com o objeto decorator, o objeto responsável pela nova funcionalidade e termina com o objeto original
- 36.
- 37. Exemplo Then myFactory.getComponentreturns return( new Header1( new Footer1 ( new SalesTicket())));
- 38. O padrão Facade Objetivo ◦Desejamos simplificar como usar um sistema existente, precisamos definir a nossa própria interface Problema ◦Precisamos utilizar apenas uma parte de um sistema complexo ou precisamos interagir com o sistema de uma maneira em particular Solução ◦A Facade apresenta uma nova interface para o cliente de um sistema existente Consequências ◦A Facade simplifica o uso do subsistema requerido ◦Como ela não é completa, certas funcionalidades podem não estar disponíveis para o cliente Implementação ◦Define uma nova classe (ou classes) que possui a interface necessária ◦Esta nova classe utiliza o sistema existente
- 39. O padrão Facade Classes do subsistema Facade
- 40. Exemplo de Facade– Antes Database Model Element Cliente A Cliente B
- 41. Exemplo de Facade– Depois Database Model Element Cliente A Cliente B Database Facade
- 42. Flyweight e Proxy Flyweight ◦Usa compartilhamento para suportar grandes quantidades de objetos, de granularidade fina, de maneira eficiente ◦Empregado em sistemas com grande número de objetos Proxy ◦Fornece um objeto representante ou um marcador de outro objeto para controlar o acesso ao mesmo ◦Empregado em algumas implementações de CORBA
- 43. Padrões de ProjetoComportamentais - Chain of Responsibility - Command - Interpreter - Iterator - Mediator - Memento - Observer - State - Strategy - Template Method - Visitor
- 44. Chain of Responsibility Evita o acoplamento entre o remetente de uma solicitação e o destinatário da solicitação, dando a mais de um objeto a chance de tratar a solicitação Encadeia os objetos receptores e passa a solicitação ao longo da cadeia até que um objeto a trate Utilizado no tratamento de eventos de usuários
- 45.
- 46. Command Encapsula umasolicitação como um objeto, permitindo a parametrização de clientes com diferentes solicitações, o enfileiramento e o registro de solicitações e o suporte a operações que possam ser, por exemplo, desfeitas Utilizado para da suporte a “desfazer”
- 47. Interpreter Dada umalinguagem, define uma representação para sua gramática juntamente com um interpretador que usa a representação para interpretar sentenças nesta linguagem Utilizado para interpretar uma linguagem com uma árvore sintática abstrata, como em compiladores de linguagens orientadas a objetos
- 48. Iterator Fornece umamaneira de acessar sequencialmente os elementos de um objeto agregado sem expor sua representação subjacente Utilizado, por exemplo, na C++ Standard Template Library
- 49.
- 50. Mediator Define umobjeto que encapsula a interação entre um conjunto de objetos Promove o acoplamento fraco ao evitar que os objetos se refiram explicitamente uns aos outros, permitindo a variação das interações independentemente Utilizado na arquitetura de aplicações Smalltalk
- 51. Memento Sem violara encapsulação, captura e externaliza um estado interno de um objeto, de modo que o mesmo possa posteriormente ser restaurado para este estado Utilizado para armazenar um instantâneo do estado do objeto sem romper sua encapsulação
- 52. O padrão Observer Objetivo ◦Define uma dependência um-para-muitos entre objetos de maneira que quando um objeto muda de estado, todas as suas dependências são notificadas e atualizadas automaticamente Problema ◦Precisamos notificar uma lista variável de objetos quando um evento ocorre Solução ◦Observers delegam a responsabilidade pelo monitoramento de um evento a um objeto central (Subject) Consequências ◦Subjects podem avisar Observers sobre evento que eles não precisam conhecer Implementação ◦Objetos que precisam ser notificados (Observers) devem ser associados ao objeto que está observando (Subject) pela ocorrência do evento ou que dispara o evento ◦Quando o evento ocorre, o Subject avisa ao Observer
- 53. Estrutura genérica dopadrão Observer
- 54. Exemplo – hardcoding Classe Responsabilidade Customer Quando um cliente é adicionado, este objeto irá fazer uma chamada aos outros objetos para ter a ação desejada WelcomeLetter Cria cartas de boas vindas para que os clientes saibam que foram adicionados ao sistema AddrVerification Verifica o endereço de qualquer cliente que o peça
- 55. Exemplo – comObserver
- 56. State Permite queum objeto altere seu comportamento quando seu estado interno muda O objeto parecerá ter mudado sua classe Utilizado em algumas implementações a pilha TCP/IP
- 57. Strategy Define umafamília de algoritmos, encapsula cada um deles e os faz intercambiáveis Permite que o algoritmo varie independentemente dos clientes que o utilizam Utilizado em alguns sistemas de otimização
- 58. Template Method Defineo esqueleto de um algoritmo em uma operação, postergando a definição de alguns passos para subclasses Permite que as subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura Utilizado em arquiteturas Application/Document/View
- 59. Visitor Representa umaoperação a ser executada sobre os elementos de uma estrutura de objetos Permite a definição de uma nova operação sem mudar as classes dos elementos sobre os quais opera Utilizado para executar uma série de operações sobre objetos que possuem interfaces diferentes, sem poluir a interface dos mesmos
- 60. Referências “The Gangof Four”. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos. Shalloway, A., Trott, J. R. Design Patterns Explained: A New Perspective on Object-Oriented Design 2nd ed. Addison Wesley Professional, 2004. Deschamps, F. Padrões de Projeto: Uma Introdução. S2i, DAS, UFSC. Grand, M. Patterns in Java Vol. 1: A Catalog of Reusable Design Patterns Illustrated with UML 2nd ed. Wiley, 2002.
- 61. Padrões de Projetode Software Algoritmos e Programação II Fábio M. Pereira