padrões de projeto de software
DESCRIPTION
Aula de Algoritmos e Programação II - Padrões de Projeto de SoftwareTRANSCRIPT
Padrões de Projeto de
Software Algoritmos e Programação II
Fábio M. Pereira
Roteiro
Introdução:
◦ O que são padrões de projeto?
◦ Motivação
Conceitos básicos:
◦ Atributos
◦ Problemas
◦ Seleção
◦ Uso
Tipos
Exemplos
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
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
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
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
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)
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
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
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
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
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
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
Padrões de Projeto de
Criação - Abstract Factory
- Builder
- Factory Method
- Prototype
- Singleton
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)
Abstract Factory
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
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.
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
the MessageBuilder 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 The MIMEParser object calls
the 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.
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
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.
Factory Method
Sem
Factory Method
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
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.
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
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;
}
}
Padrões de Projeto
Estruturais - Adapter
- Bridge
- Composite
- Decorator
- Façade
- Flyweight
- Proxy
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
Adapter
Supondo que eu tenha: E queira adicionar...
Utilizando Adapter (reuso da classe XXCircle)
Bridge
Separa uma abstração da sua
implementação, de modo que as duas
possam variar independentemente
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
Composite
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
Decorator
Exemplo
Then myFactory.getComponent returns
return( new Header1( new Footer1 ( new
SalesTicket())));
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
O padrão Facade
Classes do subsistema
Facade
Exemplo de Facade – Antes
Database
Model
Element
Cliente A
Cliente B
Exemplo de Facade – Depois
Database Model Element
Cliente A
Cliente B
Database Facade
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
Padrões de Projeto
Comportamentais - Chain of Responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Template Method
- Visitor
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
Chain of Responsibility
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”
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
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
Iterator
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
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
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
Estrutura genérica do padrão
Observer
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
Exemplo – com Observer
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
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
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
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
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.
Padrões de Projeto de
Software Algoritmos e Programação II
Fábio M. Pereira