PADRÕES DE PROJETO DE SOFTWARE AULA 01

Prévia do material em texto

PADRÕES DE PROJETO DE SOFTWARE
Aula 01
Fundamentos de padrões de projeto
Nesta aula, você irá:
Conhecer o conceito de padrão de projeto e a suas aplicações.
Entender a descrição de um padrão de projeto e como usar.
Conhecer as duas principais famílias de padrões de projeto que serão estudadas no decorrer da disciplina.
Iniciar o estudo dos padrões de projeto da família GoF.
Introdução
Projetar software OO reusável e de boa qualidade é uma tarefa difícil;
Para realizar essa tarefa a contento, projetistas experientes usam soluções de sucesso com as quais já trabalharam no passado;
Isso leva à descoberta de padrões de projeto;
Durante duas décadas, a comunidade de padrões vem se desenvolvendo de acordo com essa dinâmica.
O que é um padrão?
Maneira testada ou documentada de alcançar um objetivo qualquer;
 Padrões são comuns em várias áreas da engenharia;
 Design Patterns, ou Padrões de Projeto;
Padrões para alcançar objetivos na engenharia de software usando classes e métodos em linguagens orientadas a objeto;
Inspirado em "A Pattern Language" de Christopher Alexander, sobre padrões de arquitetura de cidades, casas e prédios;
"Design Patterns" de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, conhecidos como "The Gang of Four", ou GoF, descreve 23 padrões de projeto úteis
"Cada padrão descreve um problema que ocorre repetidas vezes em nosso ambiente, e então descreve o núcleo da solução para aquele problema, de tal maneira que pode-se usar essa solução milhões de vezes sem nunca fazê-la da mesma forma duas vezes"
Christopher Alexander, sobre 
padrões em Arquitetura
"Os padrões de projeto são descrições de objetos que se comunicam e classes que são customizadas para resolver um problema genérico de design em um contexto específico"
Gamma, Helm, Vlissides & Johnson, 
sobre padrões em software
“Um padrão é a abstração de uma forma concreta que ocorre muitas vezes em contextos específicos.” 
 Riehle & Zullighoven, 1996
“Resolve um problema. É um conceito provado. A solução não é óbvia. Descreve um relacionamento.” 
Jim Coplien, 1996
Padrões - características
Capturam soluções de projeto exaustivamente refinadas com o passar do tempo;
São o resultado de um longo processo de projeto, re-projeto, teste e reflexão sobre o que torna um sistema mais flexível, reusável e modular;
Catálogos de padrões
Um catálogo de padrões é um grupo de padrões que estão relacionados de uma certa forma e podem ser usados juntos ou independentemente:
Core JEE(Java Enterprise Edition);
PoEAA(PatternsofEnterprise Application Architecture);
POSA(Pattern-OrientedSoftware Architecture)
GRASP(General Responsibility Assignment Software Patterns/Principles)
GoF(Gang ofFour)
Introdução aos padrões de projeto
ANOS 70
Curiosamente, a ideia de padrões de projeto iniciou na área de arquitetura, através da publicação de dois livros (A Pattern Language e A Timeless Way of Building) pelo arquiteto Christopher Alexander no  final  dos  anos  70.  Alexander detectou problemas recorrentes em arquitetura e planejamento urbano e os capturou, descreveu e os formalizou em instruções que ele chamou de padrões.
1987
As ideias de Alexander permaneceram esquecidas por um bom período, até que os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da Ciência da Computação em 1987. Porém, a área de padrões de projeto começou a ganhar força e notoriedade a partir da publicação do livro Design Patterns: Elements of Reusable Object-Oriented Software por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides em 1985. Mais tardes estes autores ficaram conhecimento como a "Gangue dos Quatro" (Gang of Four) ou simplesmente GoF. 
2004
Outro marco importante na área de padrões de projeto foi a publicação do conjunto de padrões GRASP (General Responsibility Assignment Software Patterns) no livro Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development de Craig Larman em 2004. Os padrões de projeto GRASP podem ser considerados como um apoio para aplicar os conceitos de orientação a objetos de um modo metódico, racional e mais didático.
Catálogo - GoF
�
Por que aprender padrões?
Aprender com a experiência dos outros
Identificar problemas comuns em engenharia de software e utilizar soluções testadas e bem documentadas;
Utilizar soluções que têm um nome: facilita a comunicação, compreensão e documentação;
Aprender a programar bem com orientação a objetos
Os 23 padrões de projeto "clássicos" utilizam as melhores práticas em OO para atingir os resultados desejados;
Desenvolver software de melhor qualidade
Os padrões utilizam eficientemente polimorfismo, herança, modularidade, composição, abstração para construir código reutilizável, eficiente, de alta coesão e baixo acoplamento;
Descrição de Padrões de projeto
Conforme descrito anteriormente, padrões de projeto são voltados para problemas recorrentes que ocorrem no nosso dia-a-dia, seja na área de desenvolvimento de software, seja em qualquer outra área do conhecimento. Formalmente, pode-se definir um padrão de projeto da seguinte maneira:
Cada padrão descreve um problema que ocorre repetidas vezes em nosso ambiente e fornece o núcleo da solução para aquele problema, de tal maneira que pode-se usar essa  solução  milhões  de  vezes  sem  nunca  fazê-la  da  mesma  forma duas vezes.
 Os padrões de projeto são descrições de objetos que se comunicam e classes que são customizadas para resolver um problema genérico de design em um contexto específico.
Padrões de projeto
Padrões de projeto estão relacionados a diferentes níveis de abstração no desenvolvimento de aplicações orientadas a objetos, podendo aparecer ao longo de todo ciclo de análise e projeto de um sistema. Portanto a diversidade de padrões disponíveis é bastante grande, pode-se ter, por exemplo, padrões arquiteturais, padrões de análise, padrões de projeto e padrões de código. Esta disciplina está concentrada no uso de padrões de projeto direcionados para a etapa de implementação da aplicação.
Dessa forma, o aprendizado da área de padrões de projeto tem se mostrado muito promissor, a aplicação dos seus conceitos já desponta em muitas linguagens de programação orientada a objetos. Além dos benefícios tradicionais relacionados com produtividade, redução do tempo de desenvolvimento e reaproveitamento de soluções passadas, a utilização de padrões de projeto pode contribuir ainda nos seguintes aspectos (Gamma et al., 2000):
É uma abordagem complementar, auxiliam os analistas e desenvolvedores a melhor utilizar as práticas tradicionais de análise e projeto orientado a objetos, tais como abstração, encapsulamento, herança, polimorfismo, entre outros.
Auxiliam programadores inexperientes a desenvolverem soluções mais elegantes, melhor documentadas, padronizadas e reutilizáveis.
Muitos dos padrões de projeto desenvolvidos auxiliam no refatoramento da aplicação.
Auxilia na aprendizagem a partir da documentação de experiências passadas.
Documentação 
Muitas destes benefícios são conseqüências da documentação gerada para cada tipo de padrão criado, Gamma et al. (2004) recomenda as seguintes informações básicas: 
NOME
Apelido gerado para tratamento do problema abordado. O nome deve representar o conteúdo abordado, pois estabelece o primeiro nível do entendimento;
PROBLEMA
Descreve a situação em que se deve aplicar o padrão. Pode descrever um projeto específico, representar algoritmos como objetos, estruturas de classe ou objeto ou, ainda uma lista de condições que devem ser satisfeitas para que faça sentido aplicar o padrão;
SOLUÇÃO
Descreve os elementos que compõe o padrão, seus relacionamentos, responsabilidades e colaborações. Fornece uma descrição abstrata de um problema de projeto e de como um arranjo geralde elementos o resolve;
CONSEQUÊNCIAS
Apresenta os resultados e as análises de vantagens e desvantagens da aplicação do padrão. As conseqüências são importantes para avaliar alternativas de projeto e compreensão dos custos e benefícios da aplicação do padrão;
PADRÕES RELACIONADOS
Informar uma listagem dos padrões relacionados ao estudo do problema e sua solução.
Padrões GoF
No decorrer desta disciplina estudaremos duas grandes famílias de padrões de projeto: GoF e GRASP. A partir da aula de hoje iniciaremos o estudo da família de padrões GoF, a qual está divida em três grupos principais de padrões:
Padrões de Criação: 
Fornecem um guia de como instanciar objetos. Esta ação normalmente envolve decisões dinâmicas para escolher, por exemplo, qual classe instanciar ou a quais objetos delegar responsabilidade. Esse padrão nos mostra como estruturar e encapsular essas decisões. Há cinco padrões de criação GoF: Abstract Factory, Builder, Factory Method, Prototype e Singleton.
Padrões Estruturais: 
Definem caminhos comuns para a organização de diferentes tipos de objetos, facilitando sua integração e colaboração mutua. Há sete padrões estruturais GoF: Adapter,  Bridge, Composite, Decorator, Façade, Flyweight e Proxy
Padrões Comportamentais: 
São projetados para organizar, gerenciar e combinar diferentes comportamentos. Há 11 padrões comportamentais GoF: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.
Classificação dos padrões GoF segundo Metsker [2]
�
Resumo do padrões GoF
Adapter: Converter a interface de uma classe em outra interface esperada pelos clientes.
Façade: Oferecer uma interface única de nível mais elevado para um conjunto de interfaces de um subsistema.
Composite: Permitir o tratamento de objetos individuais e composições hierárquicas desses objetos de maneira uniforme.
Bridge: Desacoplar uma abstração de sua implementação, de tal forma que os dois possam variar independentemente.
Singleton: Garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela.
Observer: Definir uma dependência um-para-muitos entre objetos para que, quando um objeto mudar de estado, os seus dependentes sejam notificados e atualizados.
Mediator: Definir um objeto que encapsula a forma como um conjunto de objetos interage.
Proxy: Prover um substituto ou ponto através do qual um objeto possa controlar o acesso a outro.
Chain of Responsibility: Compor objetos em cascata para, através dela, delegar uma requisição até que um objeto a sirva.
Flyweight: Usar compartilhamento para suportar eficientemente grandes quantidades de objetos complexos.
Builder: Separar a construção de objeto complexo da representação para criar representações diferentes com mesmo processo.
FactoryMethod: Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar.
Abstract Factory: Prover interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.
Prototype: Especificar tipos a criar usando uma instância como protótipo e criar novos objetos ao copiar este protótipo.
Memento: Externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente.
TemplateMethod: Definir o esqueleto de um algoritmo dentro de uma operação, deixando alguns passos a serem preenchidos pelas subclasses.
State: Permitir a um objeto alterar o seu comportamento quando o seu estado interno mudar.
Strategy: Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis.
Command: Encapsular uma requisição como objeto, para parametrizar clientes com diferentes requisições, filas e dar suporte a ações reversíveis.
Interpreter: Dada uma linguagem, definir uma representação para sua gramática junto com um interpretador.
Decorator: Anexar responsabilidades adicionais a um objeto dinamicamente
Iterator: Prover acesso sequencial a elementos de um objeto agregado, sem expor sua representação interna
Visitor: Representar uma operação a ser realizada sobre os elementos de uma estrutura de objetos
Classificação dos 23 padrões segundo GoF*
�
FactoryMethod
"Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar. Factory Method permite que uma classe delegue a responsabilidade de instanciamento às subclasses." 
[GoF]
O padrão FactoryMethod é caracterizado por retornar uma instância de uma classe, de acordo com parâmetros informados para o método, dessa forma, ao invés do cliente (ou programador) instanciar classes utilizando o operador new, ele chama um método genérico de criação apropriado. Por exemplo, considere uma superclasse Carro com quatro classes derivadas: Vectra, Omega, Gol e Golf. Suponha agora que é necessário instanciar objetos da classe Carro em um método pertencente a classe Montadora. A sequência de comandos a seguir apresenta uma solução comumente aceita e praticada por inúmeros desenvolvedores.
public class Montadora
{
public void novoCarro(String tipo)
{
     Carro carroZero;
if(tipo.equals(“Vectra”))
      carroZero = new Vectra();
else
if(tipo.equals(“Omega”))
carroZero = new Omega();
else 
if(tipo.equals(“Gol”))
     carroZero = new Gol();
else 
if(tipo.equals(“Golf”))
    carroZero = new Golf();
}
};
FactoryMethod
�
�
�
�
�
A partir do diagrama apresentado na Figura 1, pode-se fazer as seguintes analogias com a estrutura do padrão apresentado por Gamma et al. (2000):
A classe carro é uma classe abstrata (product) que define a interface dos objetos que o método fábrica cria;
A classe montadora é a classe client, que vai solicitar instancias de carros à classe carfactory;
As classes derivadas de carro, correspondem a concreteproduct;
A classe carfactory corresponde a classe concretecreator.
Como implementar?
É possível criar um objeto sem ter conhecimento algum de sua classe concreta?
Esse conhecimento deve estar em alguma parte do sistema, mas não precisa estar no cliente
FactoryMethod define uma interface comum para criar objetos
O objeto específico é determinado nas diferentes implementações dessa interface
O cliente do FactoryMethod precisa saber sobre implementações concretas do objeto criador do produto desejado
�
Como selecionar o criador?
Para criar objetos não é mais preciso saber a classe concreta do objeto a ser criado, mas ainda é preciso saber a classe do criador.
Para escolher qual criador usar sem que seja preciso instanciá-lo com um construtor, crie uma classe Factory com um método estático que decida qual criador usar com base em um parâmetro
Prós e contras
Vantagens
Criação de objetos é desacoplada do conhecimento do tipo concreto do objeto
Conecta hierarquias de classe paralelas
Facilita a extensibilidade
Desvantagens
Ainda é preciso saber a classe concreta do criador de instâncias (pode-se usar uma classe Factory, com método estático e parametrizado que chame diretamente o Factory Method):
Abstract Factory
"Prover uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas." 
[GoF]
Estrutura de Abstract Factory
O padrão Abstract Factory apresenta um nível de abstração superior quando comparado ao padrão FactoryMethod. Apresenta como uma de suas vantagens controlar as classes de objetos criados por uma aplicação, restringindo o acesso as classes concretas e isolando os clientes das classes de implantação
Além disso, como as fábricas abstratas aparecem uma vez na aplicação, no momento de sua instanciação, tem-se facilidade para utilizar diferentes configurações, simplesmente localizando e trocando a fábrica abstrata por outra.
�
O primeiro grupo, formado pela classe carro e suas classes derivadas,representa os diferentes produtos a serem criados pelas fábricas concretas, não há informações para diferenciar os produtos conforme seu fabricante, esta diferenciação é feita pelas fábricas.
O segundo grupo formado pelas classes Montadoras e suas classes derivadas, implementando a interface e as operações que criam os produtos concretos, associados a cada tipo de fábrica. Para utilizar instanciar um determinado carro, instancia-se primeiro o fabricante e a seguir o modelo de carro desejado.
A imagem apresenta o diagrama UML com um exemplo de utilização do padrão AbstractFactory na implementação de um conjunto de classes para instanciar carros de acordo com seu respectivo fabricante, semelhante ao exemplo anterior, sobre FactoryMethod. Porém, diferente do anterior, a implementação prevê dois grupos de classes de carros: Volkswagem e General Motors, conforme a estrutura do padrão presentes no diagrama. 
Fazendo analogia com a estrutura do padrão AbstractFactory apresentado em Gamma et al (2000), tem-se as seguintes correspondências: 
A classe montadora corresponde a abstractfactory;
A classe carro corresponde a abstractproducta; 
A classe Gol corresponde a Product A3.
A classe Golf corresponde a Product A4.
As classe volks corresponde a concretefactory1;
A classe Omega  corresponde a Product A1.
A classe GM corresponde a concretefactory2; 
Nesta aula, você: 
Estudou a origem e as principais motivações para aplicar padrões de projeto em projetos de desenvolvimento de software.
Identificou as duas grandes famílias de padrões de projeto mais comumente utilizadas: gof e GRASP.
Estudou dois exemplos com aplicações práticas sobre os padrões de criação FactoryMethod e AbstractFactory.
Registro de Participação
1. Assinale a alternativa que apresenta apenas padrões de criação GoF.
 1) AbstractFactory, FactoryMethod, Builder. 
 2) AbstractFactory, FactoryMethod, Adapter. 
 3) Adapter, FactoryMethod, Builder. 
 4) Interpreter, Singleton, FactoryMethod. 
 5) Builder, Singleton, FactoryMethod. 
 
2.Qual padrão de projeto permite a criação de objetos através de um método genérico, sem que o cliente precise ter conhecimento de qual classe concreta está sendo usada?
 1) AbstractFactory. 
 2) Builder. 
 3) Template Method. 
 4) Singleton. 
 5) Mediator. 
 
3. Qual padrão de projeto permite a criação de uma família de objetos relacionados ou dependentes sem especificar a classe concreta que será utilizada?
 1) Mediator. 
 2) Builder. 
 3) Template Method. 
 4) Singleton. 
 5) AbstractFactory. 
 
Erich Gamma e outros.
Christopher Alexander
PADRÕES DE PROJETO DE SOFTWARE � PAGE �1�
PADRÕES DE PROJETO DE SOFTWARE � PAGE �1�