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.

1. Padrões de Projeto de Software
Algoritmos e Programação II
Fábio M. Pereira

2. Roteiro
Introdução:
◦O que são padrões de projeto?
◦Motivação
Conceitos básicos:
◦Atributos
◦Problemas
◦Seleção
◦Uso
Tipos
Exemplos

3. Introdução
Engenharia de Software 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 projeto de 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
Aumento da 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 por padrõ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 por padrõ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ência que 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 um padrã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 um padrã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ões de 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ões de 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 (Gang of 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 Projeto de Criação
- Abstract Factory
- Builder
- Factory Method
- Prototype
- Singleton

15. Abstract Factory
Fornece uma 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. Abstract Factory

17. Builder
Separa a construçã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 an abstract 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 class also 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
Define uma 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 os tipos 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 in this 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 do padrã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 Projeto Estruturais
- Adapter
- Bridge
- Composite
- Decorator
- Façade
- Flyweight
- Proxy

29. Adapter
Converte a interface 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. Adapter

31. Supondo que eu tenha:
E queira adicionar...
Utilizando Adapter (reuso da classe XXCircle)

32. Bridge
Separa uma abstração da sua implementação, de modo que as duas possam variar independentemente

33. Composite
Compõe objetos em 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. Composite

35. Decorator
Atribui responsabilidades adicionais 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. Decorator

37. Exemplo
Then myFactory.getComponent returns 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 Projeto Comportamentais
- 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. Chain of Responsibility

46. Command
Encapsula uma solicitaçã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 uma linguagem, 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 uma maneira de acessar sequencialmente os elementos de um objeto agregado sem expor sua representação subjacente
Utilizado, por exemplo, na C++ Standard Template Library

49. Iterator

50. Mediator
Define um objeto 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 violar a 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 do padrão Observer

54. Exemplo – hard coding
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 – com Observer

56. State
Permite que um 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 uma famí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
Define o 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 uma operaçã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 Gang of 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 Projeto de Software
Algoritmos e Programação II
Fábio M. Pereira