Padroes de projeto 1

Prévia do material em texto

Padroes de projeto 
Ementa 
Aula 1 – Ementa e Disicussões iniciais. Revisão (classes, objetos, Diagrama de classes, doagrama de 
sequencias). 
Aula 2 – Estilos arquiteturais. Fluxo de dados (sequencial e batch), call/return (camadas/mvc, 
bibliotecas, frameworks e componentes), processos de comunicação (cliente-servidor, P2P), repositorio 
de dados (black board e SGBD) e máquinas virtuais (interpretadores e sistemas baseados em regras) 
Aula 3 – Introdução aos Padrões de projeto. Importância. Visão particular a manifestação dos catálogos 
diversos. Introdução ao padrão GOF. 
Aula 4 – Padrões de Criação (Abstract Factory, Builder, Factory Method). 
Aula 5 – Padrões de Criação (Protoype, Singleton). Padrões estruturais (Adapter, Brigde e Composite). 
Aula 6 – Padrões Estruturais (Decorator, Facade, Flyweight, Proxy). 
Aula 7 – Padrões Comportamentais (Chain of Responsibility, Command). Revisão. 
AV1 (8 pts). Entrega da lista de exercícios 1 (2 pts). 
Aula 8 – Correção da AV1. 
Aula 9 – Padrões Comportamentais (Interpreter, iterator e mediator). 
Aula 10 – Padrões Comportamentais (Memento, Observer, State) 
Aula 11 – Padrões Comportamentais (Strategy, template method e visitor) 
Aula 12 – Introdução aos Padrões Grasp. 
Aula 13 – Padrão Criador, controlador, acoplamento fraco e coesão alta. 
Aula 14 – Polimorfismo, Inversão pura. 
Aula 15 – Indireção, varições protegidas. 
AV2 (8 pts). Entrega da atividade estruturada (2 pts - individual) 
Aula 16 – Correção da AV2 
AV3 (10 pts) 
Bibliografia – Padrões de projeto Erich gamma et al. 
 
 
 
 
 
 
31/07/2013 
Revisão O.O. 
Os sistemas de implementação atuais procuram seguir um paradigma de implementação que dá ênfase 
ao encapsulamento de atributos e operações. Tais propriedades são consubstanciadas em um objeto, 
descritor de uma instância de uma classe e suas associações. 
A principal ferramenta para representação das classes e objetos se dá através da UML. A Unified 
Modeling Language (UML) permite não só a modelagem de aspectos do domínio do sistema, mas 
também de mapear um projeto sob o ponto de vista computacional. Na UML, representamos uma 
classe da seguinte maneira: 
 
 
 
 
 
 
 
 
Os atributos e operações privadas indicam que não é possível o acesso aos valores por parte de outros 
objetos. Os atributos e operações protegidas permitem o acesso aos valores se e somente se os objetos 
forem de Classes Filhas*. Por fim, os atributos e operações públicos podem ser acessados por quaisquer 
objetos. 
As classes podem ser abstratas (<<abstract>>), o que indicam que não podem ser instanciadas. São 
geralmente utilizadas em taxonomias (Heranças). 
 
 
 
 
 
 
 
Por vezes a herança restringe o uso de aplicações devido a sua necessidade de criar vínculos fortes entre 
as classes. Em uma gama de sistemas precisamos especificar contratos, consubstanciados através de 
 
<<abstract>>nome da classe 
 
nom 
- atributo privado 
# atributo protegido 
+ atributo público 
 
- operação privada 
# operação protegida 
+ operação pública 
Classe Pai 
Classe Filho 
opcional 
 
 
interfaces. As interfaces são um conjuntos de operações (métodos) necessários para adequação ou 
fornecimento de um serviço. Na UML é assim que se representa uma interface: 
 
 
 
 
 
 
Uma classe deve implementar uma interface. 
 
 
 
 
 
 
Aula 2 – 07/08/2013 
Continuação: Revisão O.O. 
Na aula passada revemos o uso de classes e interfaces, alpem de truqies estritamente ligados à 
Linguagem de Programação. Revemos as idéias de instâncias de interfaces. Façamos, agora, mais alguns 
experimentos. 
 
 
 
 
 
 
 
 
 
 
<<interface>> 
Nome da interface 
 
 
+ op 1 
+ op 2 
+ op 3 
 A 
<<interface>> I 
Op1 
Nome da interface 
 A 
+op1() 
 B 
-b1 
+op2() 
 
 C 
-c1 
+op3() 
 
<<Interface>> 
+op 
 
 
Introdução às Arquiteturas de Software 
Muitos profissionais da área de T.I. rcebem o título de arquiteto. Eles geralmente são profissionais com 
larga experiência e se utilizam de um conjunto de soluções e filosofias para construção de um projeto de 
software. 
Afinal, o que é uma arquitetura de software? Segundo Mendes, uma arquitetura de software é detimida 
como um: 
“Conjunto de componentes de sistema, seus inter-relacionamentos, princípios e diretrizes guiando o 
projeto ao longo do tempo.” 
Os benefícios de uma arquitetura de software está amplamente difundida sobre os elementos básicos 
de um ciclo de desenvolviment. O primeiro benefício se refere ao controle da complexidade, pois a 
decomposição em componentes permeite a atribuição de responsabilidades clares e simplificação no 
reuso. 
As responsabilidades e a possibilidade de reuso em arquiteturas normalmente se consubstancia em 
componentes que são nomeados de acordo com a sua granularidade (Frameworks, bibliotecas, 
subsistemas, etc.). Além disso, do ponto de vista de gerência de projetos, a decomposição decorrente 
permiteuma estrutura organizacional matricial. 
 
Aula 3 – 14/08/13 
Estilos Arquiteturais de Software 
*Grupo: Fluxo de Dados 
O grupo de fluxo de dados consiste em um conjunto de estilos que determinam de forma de 
sequencialmente dos dados no sistema. 
-Batch 
 
 
 
 
Neste estilo, os passos do processamento são independentes logicamente, mas possuem uma ordem 
explícita. Cada passo roda um por vez, de modo que a saída de uma seja a entrada para outro processo, 
exceto pelo 1º e o último passo. 
- Pipes and Filters 
 
 
VALIDAR ORDERNAR ATUALIZAR 
Fluxo de 
dados 
Pipes 
Processa 
Filter 
 
 
Neste estil, o fluxo linear de dados passa pela entrada do componente filter, submete-se ao 
processamento e é enciado para saída. Esta, por sua vez, envia o resultado por meio de uma tubulação 
(Pipe) para outro nó. 
*Grupo: Call/Return 
-MVC (Model/ View/ Controller) (ou camadas) 
Muitas aplicações necessitam que haja uma separação entre o modelo de negócio e as funções de 
interesse e de controle. 
Neste estilo, as camadas são necessariamente obrigadas a manter qualquer tipo de interface apenas 
com as suas vizinhas mais próximas. Genericamente, são chamadas de arquiteturas de camadas, mas 
tiveram seu conceito atrelado ultimamente à aplicações comerciais voltadas para internet. 
Camada 1 
Camada 2 
Camada 3 
Camada N 
 
No âmbito da internet, a idéia da separação de camadas é relativa ao baixo acoplamento entre a 
interface de visualizalçao (view), as classes de controle (controller) e as classes de domínio (Model). 
De certa forma, o MVC está presente em outros estilos arquiteturais, causando uma certa discordância 
entre a literatura. 
O estilo em camadas é um dos mais utilizados atualmente, estando presente em aplicações de diversos 
tipos, tal qual o conhecido TCP/IP. 
- Frameworks/Componentes/Bibliotecas 
Uma das grandes metas a serem alcançadas no desenvolvimento de um sistema é a REUSABILIDADE. O 
agrupamento de uma parte do software como uma caixa que possui uma entrada e uma sáida tem sido 
a maneira como elementos comuns do sustema são reaproveitados. 
As caixas que estses estilos arquiteturais se referem estão classificadas quanto ao nível de detalhamento 
que elas oferecem. 
- Caixa Branca: todo código a ser reutilizado está disponível para visualização. Geralmente necessita que 
o desenvolvedor tenha algum domínio do código a ser reutilizado. 
- Caixa Preta: todo código está oculto para o desenvolvedor. Existe apenas um conjunto de operações a 
serem realizadas dada as respostas esperadas.- Caixa Cinza: Exige algum conhecimento do desenvolvedor, mas pode ser usado de uma forma 
degradada caso necessário. 
 
 
Caixa Branca 
Código 
particular 
E Caixa Preta 
S 
S E 
Caixa Cinza S 
Código 
particular 
E 
E 
 
 
As bibliotecas são geralmente produzidas como uma caixa preta, de modo que as operações comuns 
possam ser importadas em qualquer instante por programas distintos. Os componentes diferem das 
bibliotecas em suas granularidade. Geralmente estão associados à requisitos e possuem uma ou mais 
bibliotecas inter-conectadas. Alguns componentes, principalmente os softwares-livres, são caixas 
brancas em função de seus objetivos. Os frameworks são caixas cinzas. Constituem um arcabouço básico 
para construção de sistemas, fornecendo os códigos bases que precisam de ajustes para o domínio de 
trabalho. 
Grupo: Comunicação 
- Sistema cliente-servidor 
Este estilo arquitetural define papeis de comunicação entre processos (programas). 
Se diz que um processo é cliente se este for requisições a um servidor. 
 
 
Na arquitetura cliente-servidor é estabelecido um protocolo de comunicação. Se diz que o cliente é 
gordo e um servidor é magro quando a maioria do processamento reside no cliente. No contrário, se diz 
que um servidor é gordo e o cliente é magro. 
Uma das vantagens associadas a este estilo está ao baixo acoplamento de processamento. Em contra-
partido, os gargalos decorrentes de um possível número maior de clientes incorre em falhas estruturais 
e problemas de escalabilidade. 
-P2P (peer-to-peer) 
Neste estilo cada participante possui autonomia de processamento, ** uma clara independência. Os 
serviços e requisição podem continuar operando, mesmo com uma baixa: 
 
 
 
O principal ponto negativo desta abordagem reside na manutenção de possíveis conseqüências entre os 
nós. 
Estilos Arquiteturais (continuação) 
Grupo: Máquinas Virtuais 
- Interpretadores: os interpretadores consistem em uma camada de abstração independente. São muito 
comuns em máquinas virtuais. Nesse contexto, os softwares compilados executam por meio de 
chamadas a interfaces. A camada de abstração funciona como um “meio de campo” entre o hospedeiro 
e o cliente. 
Cliente Servidor 
Nó Nó 
Nó Nó 
 
 
- Sistemas baseados em regras: Estilo arquitetural que determina um conjunto de regras, geralmente 
em uma lógica proposicional, objetivando a inferência sobre um determinado conjunto de fatos. São 
consideradas máquinas virtuais uma vez que as regras sçao independentes do software, código ou 
sistema hospedeiro. 
 
 
 
 
 
 
- Blackboard: este estilo arquitetural consiste em um repositório para gravação e consulta por software 
clientes. Não há, nesta abordagem, um sequenciamento relativo ao uso do repositório. 
 
 
 
 
 
- Banco de Dados: Também consiste em um repositório compartilhado, mas pode eventualmente 
possuir um grau de distribuição. Difere do BlackBoard pois necessita de sincronização explícita. 
 
 
 
 
 
Introdução aos Padrões de Projeto 
Padrões de projeto nada mais são que uma coletânia de soluções propostas e utilizadas por diversos 
profissionais desde a década de ’60. 
Os padrões de projeto resolvem problemas específicos, tornando, também, o projeto orientado à objeto 
mais flexível, reutilizável e escalável. 
Para Alexander, “cada padrão descreve um problema no nosso ambiente e o cerne da sua solução, de 
tal forma que você possa usar essa solução mais de um milhão de vezes, sem nunca fazê-lo da mesma 
maneira.” 
Entrada Saída 
Software 1 
interpretador 
Software N 
hospedeiro 
Regra 1 
Regra 2 
Regra 3 
Menória de 
trabalho 
Máquina de 
inferência 
 
Ap4 Ap1 
Ap2 Ap3 
Cliente 1 Cliente N 
Base de Dados 
 
 
É importante ressaltar que os Padrões GOF (Gang of Four) dos autores Gamma et al., principal objeto de 
nosso estudo, dão diretrizes de como solucionar o problema, mas não consistem em uma receita de 
bolo imutável. Em geral, um padrão de projeto tem os seguintes aspectos: nome, problema, solução e 
conseqüências. 
Apesar de adotarmos a Orientação Objeto como mecanismo de explicitação dos padrões, não há nada 
que impeça o uso em linguagens aderentes a outros paradigmas. 
Gamma et al. define que a melhor política de programação para consubstanciação dos Padrões reside 
no que ele chama de “Programação para interfaces” 
Existe um benefício claro: 
*Os clientes (objetos) não conhecem tipos específicos, apenas interfaces e classes abstratas. 
Como selecionar um padrão? 
Depois de entendido e modelado o domínio, procure destacar que arquitetura você julga ser 
pertinentes para o domínio da aplicação. 
O projetista de sistema deve estudar como os padrões se relacionam. É importante que os padrões 
sejam consideradas quanto as suas afividades. 
-Padrão Abstract Factory (Fábrica Abstrata) 
A intenção deste padrão é fornecer uma “fábrica” de objetos sem que os clientes conheçam 
efetivamente as classes concretas. 
Considere aplicar o padrão Abstract Factory quando um sistema deve ser independente de como os seus 
produtos são criados ou representados. É especialmente válido quando se deseja criar uma família de 
produtos. 
 
*void meramente ilustrativo. 
Conseqüências do Abstract Factory 
- isola classes concretas; 
- troca de família de produtos; 
 
 
- Promove harmonia entre produtos; 
- É difícil suportar novos tipos; 
Padrão de Projeto Builder 
O objetivo do padrão de projeto builder é promover o desacoplamento durante a construção de objetos 
complexos. 
O padrão builder é utilizado quando desejamos especificar um algoritmo para criação de um objeto 
complexo de forma independentes das partes que o compõe. 
 
 Director: para todos os objetos buildPart() 
Conseqüências 
- Permite variar a representação interna de um produto; 
- isola o código para construção e representação; 
- Oferece um controle mais fina sobre a construção de um produto; 
 
Padrão de Projeto Factory Method 
O principal objetivo do padrão factory method está relacionado ao fornecimento de um guia para 
postergação da criação de objetos por parte das classes filhas. 
O padrão Factory Method é comumente usado para definirmos um Framework. Desejamos que os 
clientes do Framework decidam a melhor maneira de usá-lo. Este padrão é geralmente utilizado quando 
uma classe não pode antecipar quais os objetos devem ser criados. 
As classes filhas de um cliente deverão armazenar o conhecimento sobre a construção do objeto. 
 
 
 
Conseqüências 
 Fornece ganchos para subclasses; 
 Conecta hierarquias de classes paralelas; 
Exemplo: 
 
 
Padrão de Projeto Prototype 
O objetivo do padrão Prototype é estabelecer uma maneira de produzir cópias fiéis de objetos. O 
Prototype deve ser independente de como os produtos são criados , compostos e representados. É 
também utilizado quando as classes a instanciar forem especificadas em tempo de execução. 
 
Conseqüências 
- Adiciona e remove produtos em tempo de execução; 
- Especifica novos objetos pela variação de valores; 
- Difícil implementação do clone(). 
 
 
Padrão de Projeto Singleton 
O conceito por trás do padrão de projeto Singleton reside na necessidade de se garantir a penas uma 
única instância de uma classe. Ou seja, não permitir mais de um objeto. 
A solução reside em tornar a classe responsável por manter esta unicidade. 
 
 
 
Exemplo: 
 
- Consequências: 
* Acesso controlado a instância única. 
* Espaço de nomes reduzidos. 
* Variantes para controle de vários objetivos. 
Padrão de Projeto Adapter 
A intençãode iso do padrão de projeto Adapter reside na compatibilidade de uso de frameworks e 
bibliotecas com interfaces à priori conflitantes ou mesmo imutáveis para determinados clientes. 
 
- Consequências: 
* Permite o Adapter substituir algum comportamento de adaptee 
 
 
Singleton 
Static instance()