Arquitetura e Projeto Orientado a Objetos

Padres Arquiteturais e de Projeto para Desenvolvimento de Software Orientado a ObjetosDr. Gilleanes Thorwald Araujo Guedesgtaguedes@gmail.comBibliografia BsicaSOMMERVILLE, Ian. Engenharia de Software 9 Edio. Addison Wesley. 2011.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padres de projeto: solues reutilizveis de software orientado a objetos. Porto Alegre, RS: Bookman, 2000.

LARMAN, Craig. Utilizando UML e Padres 3. Edio. Porto Alegre: Bookman, 2007.

Bibliografia ComplementarGUEDES, G. UML 2 Uma Abordagem Prtica. 2.ed. So Paulo: Novatec, 2011. DEITEL, P. J.; DEITEL, H. M. Java: como programar. 8.ed. So Paulo: Pearson, 2010. BRAUDE, E. Projeto de Software - Da programao arquitetura: uma abordagem baseada em java. Porto Alegre: Bookman, 2005. MEUNIER, R.; SOMMERLAD, P.; BUSCHMANN, F.; STAL, M.; ROHNERT, H. Pattern-oriented software architecture: a system of patterns. Hoboken, NJ: John Wiley & Sons, 1996.HORSTMANN, C. Padres de Projeto Orientados a Objetos. 2.ed. Porto Alegre: Bookman, 2007.EmentaConceitos bsicos e prticos sobre os seguintes padres mais relevantes: Arquiteturais; Padres de projeto de criao; Padres de projeto estruturais; Padres de projeto comportamentais.ObjetivosAprender os conceitos bsicos dos padres arquiteturais e dos padres relacionados ao desenvolvimento de software orientado a objetos. Projeto de ArquiteturaPreocupa-se com a compreenso de como um sistema deve ser organizado e com sua estrutura geral.

No processo de desenvolvimento de software, o projeto de arquitetura o primeiro estgio do projeto de software. Projeto de ArquiteturaPonto de ligao entre a engenharia de requisitos e o projeto;

Identifica os componentes estruturais de um sistema e os relacionamentos entre eles.

Produz um modelo de arquitetura que descreve como o sistema est organizado em um conjunto de componentes (subsistemas) de comunicao.Arquitetura de um Sistema de Controle Robotizado de Empacotamento

Fonte: Sommerville (2011)Projeto de ArquiteturaEm processos geis, aceito que um estgio inicial do processo de desenvolvimento se preocupe com o estabelecimento de uma arquitetura global do sistema.

O desenvolvimento incremental de arquiteturas geralmente no bem-sucedido.

A refatorao de uma arquitetura geralmente cara.Projeto de ArquiteturaExiste uma considervel sobreposio entre os processos de engenharia de requisitos e de projeto de arquitetura.

A decomposio de arquitetura normalmente necessria para estruturar e organizar a especificao. Projeto de ArquiteturaComo parte do processo de engenharia de requisitos, pode-se propor uma arquitetura abstrata de sistema em que sejam associados grupos de funes ou recursos aos componentes ou subsistemas.

Pode-se ento usar essa decomposio para discutir com os stakeholders os requisitos e recursos do sistema.Projeto de ArquiteturaO projeto de arquitetura de software pode ser:

Arquitetura em Pequena Escala:

Onde se projeta a arquitetura de programas individuais, ou seja, como um software dividido em componentes.Projeto de ArquiteturaArquitetura em Grande Escala:

Enfoca a arquitetura de sistemas corporativos complexos que incluem outros sistemas, programas e componentes de programas.

Distribuem-se por diversos servidores e podem pertencer e ser geridos por diferentes empresas.Projeto de ArquiteturaOs componentes individuais implementam os requisitos funcionais do sistema.

Os requisitos no funcionais dependem da arquitetura do sistema - como os componentes esto organizados e se comunicam.

A arquitetura de software afeta o desempenho, a robustez, a capacidade de distribuio e a manutenibilidade de um sistema.Projeto de ArquiteturaVantagensH trs vantagens em projetar e documentar a arquitetura de software:

Comunicao com os Stakeholders:

A arquitetura uma apresentao de alto nvel do sistema e pode ser usada como um foco de discusso com os stakeholders.Projeto de ArquiteturaVantagensAnlise de sistema: Tornar explcita a arquitetura do sistema, em um estgio inicial, exige que o sistema seja analisado principalmente em termos de requisitos no funcionais. As decises de projeto de arquitetura tm um efeito profundo sobre a possibilidade do sistema atender ou no aos requisitos crticos, como desempenho, confiabilidade e manutenibilidade.Projeto de ArquiteturaVantagensReuso em Larga Escala:

Um modelo de uma arquitetura de sistema uma descrio compacta e gerencivel de como um sistema organizado e como os componentes interoperam.

A arquitetura do sistema geralmente a mesma para sistemas com requisitos semelhantes e pode apoiar o reuso de software.Decises de Projeto de ArquiteturaO projeto de arquitetura define uma forma de organizao para satisfazer aos requisitos funcionais e no funcionais de um sistema.

O projeto de arquitetura depende:

Do tipo de sistema a ser desenvolvido;Da formao e experincia do arquiteto;Dos requisitos especficos para o sistema. Decises de Projeto de ArquiteturaDurante o projeto de arquitetura, os arquitetos precisam tomar uma srie de decises estruturais que afetam profundamente o sistema e seu processo de desenvolvimento.

Com base em seus conhecimentos e experincia, eles precisam considerar as seguintes questes fundamentais:

Existe uma arquitetura genrica de aplicao que pode atuar como um modelo para o sistema?

Decises de Projeto de ArquiteturaComo o sistema ser distribudo?Que padres ou estilos de arquitetura podem ser usados?Qual ser a abordagem fundamental para se estruturar o sistema?Como os componentes estruturais do sistema sero decompostos em subcomponentes?Que estratgia ser usada para controlar o funcionamento dos componentes do sistema?

Decises de Projeto de ArquiteturaQual a melhor organizao de arquitetura para satisfazer os requisitos no funcionais do sistema?

Como o projeto de arquitetura ser avaliado?

Como a arquitetura do sistema deve ser documentada?

Decises de Projeto de ArquiteturaPara sistemas embarcados e sistemas para computadores pessoais no necessrio projetar uma arquitetura distribuda.

No entanto, a maioria dos sistemas de grande porte so distribudos entre vrios servidores.

A escolha da arquitetura de distribuio uma deciso importante que afeta o desempenho e a confiabilidade do sistema.Decises de Projeto de ArquiteturaA arquitetura de um sistema de software pode se basear em um determinado padro. Um padro de arquitetura descreve uma organizao de sistema, como uma organizao cliente-servidor ou arquitetura em camadas.

Os padres de arquitetura capturam a essncia de uma arquitetura que tem sido usada em diferentes sistemas.Decises de Projeto de ArquiteturaAo tomar decises sobre a arquitetura de um sistema, deve-se conhecer:

Os padres existentes;

Em que situaes podem ser usados;

Quais so seus pontos fortes e fracos.

Decises de Projeto de ArquiteturaOs requisitos no funcionais precisam ser considerados ao se projetar a arquitetura do sistema, para que esta possa atend-los.

Alguns desses requisitos so:Decises de Projeto de ArquiteturaDesempenho:

A arquitetura deve ser projetada para inserir as operaes mais importantes dentro de um pequeno nmero de componentes, instalados no mesmo servidor, ao invs de distribudos pela rede. Decises de Projeto de ArquiteturaEstes componentes podem ser relativamente grandes, em vez de pequenos de baixa granularidade, o que reduz o nmero de comunicaes entre eles.

Tambm pode-se considerar a organizao do sistema de run-time, que permite que o sistema seja replicado e executado em diferentes servidores.

Decises de Projeto de ArquiteturaProteo:

Deve ser usada uma estrutura em camadas para a arquitetura;

Os ativos mais crticos devem estar localizados nas camadas mais internas, com alto nvel de validao de proteo aplicado a elas.Decises de Projeto de ArquiteturaSegurana:

As operaes de segurana devem se localizar em um pequeno nmero de componentes;Isso reduz custos e problemas de validao de segurana;Fornece sistemas de proteo relacionados que podem desligar o sistema de maneira segura em caso de falha. Decises de Projeto de ArquiteturaDisponibilidade:

A arquitetura deve ser projetada para incluir componentes redundantes, para que seja possvel substituir e atualizar componentes sem parar o sistema. Decises de Projeto de ArquiteturaManuteno:

A arquitetura deve ser projetada a partir de componentes autocontidos de baixa granularidade que podem ser rapidamente alterados;

Os produtores de dados devem ser separados dos consumidores, e estruturas de dados compartilhadas devem ser evitadas.Decises de Projeto de ArquiteturaH um conflito potencial entre essas arquiteturas.

O uso de componentes de grande porte melhora o desempenho enquanto o uso de componentes pequenos de baixa granularidade melhora a manutenibilidade.Padres de ArquiteturaSo descries abstratas, estilizadas, de boas prticas experimentadas e testadas em diferentes sistemas e ambientes.

Um padro de arquitetura deve descrever uma organizao de sistema bem-sucedida em sistemas anteriores.

Deve incluir informaes de quando o uso desse padro adequado e seus pontos fortes e fracos.Padro MVC Model-View-ControllerAs noes de separao e independncia so fundamentais para o projeto de arquitetura, porque permitem que alteraes sejam localizadas.

O padro MVC separa os elementos de um sistema, permitindo mud-los de forma independente.

Padro MVC Model-View-ControllerO sistema estruturado em trs componentes lgicos que interagem entre si:

Modelo: gerencia o sistema de dados e as operaes associadas a esses dados.Viso: define e gerencia como os dados so apresentados ao usurio.Controlador: gerencia a interao do usurio e as repassa para a Viso e o Modelo.Padro MVC Model-View-Controller usado quando existem vrias maneiras de se visualizar e interagir com os dados.

Tambm utilizado quando so desconhecidos os futuros requisitos de interao e apresentao de dados.Padro MVC Model-View-ControllerPermite que os dados sejam alterados de forma independente de sua representao e vice-versa.

Apoia a apresentao dos mesmos dados de maneiras diferentes, com as alteraes feitas em uma representao aparecendo em todas elas.Padro MVC Model-View-Controller

Fonte: Sommerville (2011)Padro MVC Model-View-Controller

Fonte: Sommerville (2011)Padro MVC Model-View-Controller

Padro MVC Model-View-Controller

Padro de Arquitetura em CamadasO sistema organizado em camadas separadas.

Cada camada s depende dos recursos e servios oferecidos pela camada imediatamente abaixo dela.Padro de Arquitetura em CamadasEssa abordagem permite o desenvolvimento incremental de sistemas.

Quando uma camada desenvolvida, alguns dos servios prestados por ela podem ser disponibilizados para os usurios.Padro de Arquitetura em CamadasA arquitetura tambm mutvel e portvel.

Enquanto sua interface for inalterada, uma camada pode ser substituda por outra equivalente.

Alm disso, quando a camada de interfaces muda ou tem novos recursos adicionados, apenas a camada adjacente afetada.

Padro de Arquitetura em CamadasComo sistemas em camadas localizam dependncias das mquinas em camadas internas, isso facilita o fornecimento de implementaes de multiplataformas de um sistema de aplicao.

Apenas as camadas internas dependentes da mquina precisam ser reimplementadas para levar em conta os recursos de um sistema operacional diferente ou banco de dados.

Padro de Arquitetura em CamadasVantagens:

Desde que a interface seja mantida, permite a substituio de camadas inteiras.

Recursos redundantes podem ser fornecidos em cada camada para aumentar a confiana do sistema.Padro de Arquitetura em CamadasDesvantagens: Pode ser difcil proporcionar uma separao entre as camadas;Uma camada de alto nvel pode ter de interagir diretamente com camadas de baixo nvel, ao invs da camada abaixo dela. O desempenho pode ser afetado devido aos mltiplos nveis de interpretao de uma solicitao de servio, uma vez que so processados em cada camada.Padro de Arquitetura em Camadas

Fonte: Sommerville (2011)Padro de Arquitetura de RepositrioA maioria dos sistemas que usam grandes quantidades de dados organizada em torno de um banco de dados ou repositrio compartilhado.

Esse modelo adequado para aplicaes nas quais os dados so gerados por um componente e usados por outro.

Padro de RepositrioOs subsistemas precisam trocar informaes para que possam trabalhar em conjunto.

Existem duas maneiras para fazer isto:

Os dados compartilhados so mantidos em um banco de dados central acessado pelos subsistemas. Esse modelo chamado de modelo de repositrio;Padro de RepositrioCada subsistema mantm seu prprio banco de dados.

Os dados so intercambiados com outros subsistemas por meio de mensagens.Padro de Repositrio

Fonte: Sommerville (2011)Padro de RepositrioVantagens e Desvantagens uma maneira eficiente de compartilhar grandes quantidades de dados.

No h necessidade de transmitir os dados de um componente para outro.Padro de RepositrioVantagens e DesvantagensPorm, os componentes devem concordar com o modelo de dados de repositrio.

Pode ser difcil integrar novos componentes se seus modelos de dados no se adequarem ao esquema estabelecido.Padro de RepositrioVantagens e DesvantagensOs componentes que produzem dados no precisam saber como esses dados so utilizados pelos outros componentes.

Alm disso so independentes, eles no precisam saber da existncia uns dos outros.

A desvantagem maior deste padro, que o repositrio um ponto nico de falha que pode afetar todo o sistema.Padro de RepositrioVantagens e DesvantagensAtividades como backup, segurana, controle de acesso e recuperao so centralizadas e de responsabilidade do gerente de repositrio.

As ferramentas podem focalizar suas principais funes, sem se preocupar com essas questes.Padro de RepositrioVantagens e DesvantagensPorm, diferentes componentes podem ter diferentes requisitos para polticas de proteo, recuperao e backup.

O modelo de repositrio impe a mesma poltica a todos os componentes.Padro de RepositrioVantagens e Desvantagens simples e direto integrar novas ferramentas, desde que sejam compatveis com o modelo de dados estabelecido.

Contudo, pode ser difcil distribuir o repositrio em uma srie de mquinas.

Embora seja possvel distribuir um repositrio logicamente centralizado, pode haver problemas de redundncia e inconsistncia de dados.Arquitetura Cliente-Servidor organizado como um conjunto de servios e servidores e clientes que solicitam os servios.

Este modelo compe-se principalmente de:

Um conjunto de servidores que oferecem servios a outros componentes. Arquitetura Cliente-ServidorUm conjunto de clientes que solicitam os servios oferecidos pelos servidores.

Uma rede que permita aos clientes acessar esses servios.

A maioria dos sistemas cliente-servidor implementada como sistemas distribudos, conectados atravs de protocolos de internet.Arquitetura Cliente-ServidorA vantagem principal deste modelo que ele uma arquitetura distribuda, permitindo o uso efetivo de sistemas de rede com muitos processadores distribudos.

fcil incluir um novo servidor e integr-lo ao sistema ou fazer a atualizao dos servidores de modo transparente, sem afetar outras partes do software. Arquitetura Cliente-ServidorOs clientes podem ter de saber os nomes dos servidores e os servios que eles fornecem.

No entanto, os servidores no precisam conhecer a identidade dos clientes ou quantos clientes esto acessando seus servios.

Os clientes acessam os servios fornecidos por um servidor por meio de chamadas de procedimento remoto usando um protocolo de solicitao-resposta.Arquitetura Cliente-Servidor

Fonte: Sommerville (2011)Arquitetura Cliente-ServidorNo h nenhum modelo de dados compartilhado e os componentes normalmente organizam seus dados de diferentes modos.

Isso significa que modelos especficos de dados podem ser estabelecidos para cada servidor, o que permite otimizar seu desempenho. Arquitetura Cliente-ServidorPorm a falta de um modelo de referncia compartilhada para dados pode significar que difcil prever problemas na integrao de dados a partir de um novo servidor.

Cada servidor deve assumir a responsabilidade por atividades de gerenciamento de dados, como backup e recuperao.Sistemas Distribudos MiddlewareOs componentes em um SD podem ser implementados em diferentes linguagens e podem ser executados em diferentes tipos de processador.

Os modelos de dados, representao de informaes, protocolos para comunicao podem ser todos diferentes.MiddlewareUm SD requer um software que possa gerenciar essas diversas partes e assegurar que elas possam se comunicar e trocar dados.

Middleware o termo utilizado para se referir a esse software.

Um middleware pode ser visto como uma camada de software intermediria localizada entre o sistema operacional e a aplicaoMiddlewareO middleware costuma ser implementado como um conjunto de bibliotecas e um sistema de tempo de execuo para gerenciar a comunicao.

O middleware normalmente instalado em cada computador do sistema distribudo.Middleware

Fonte: Sommerville (2011)MiddlewareO middleware fornece dois tipos de suporte:

Suporte a interao:Coordena as interaes entre componentes. Fornece transparncia da localizao os componentes no precisam saber os locais fsicos dos outros componentes. Suporta a converso de parmetros se diferentes linguagens forem usadas para implementar componentes.MiddlewarePrestao de servios comuns:

Fornece implementaes reusveis de servios que podem ser exigidas por vrios componentes, como servios de proteo (autenticao e autorizao).

Usando esses servios, os componentes podem interoperar e prestar servios de maneira consistente.Tipos de MiddlewareMiddlewares TransacionaisSuportam transaes sncronas;Coordenam requisies entre clientes e servidores.Vantagens:Componentes se mantm consistentes;Bastante confiveis;Boa performance;Escalonamento e priorizao de solicitaes.

Tipos de MiddlewareMiddlewares TransacionaisDesvantagens:Ausncia de padronizao para descrever servios;Executa numa menor quantidade de plataformas;Serializao (marshalling) e deserializao (unmarshalling) precisam ser implementados manualmente.Middlewares Orientados a Mensagens Message Queuing (Fila de Mensagens)Comunicao indireta;Assincrona;Mensagens enviada para filas;Message Passing (Passagem de Mensagens)Comunicao direta;Sncrona;Middlewares Orientados a Mensagens Vantagens:Suporta comunicao em grupo;Confiabilidade;Amplo suporte a protocolos de rede.Desvantagens:Escalabilidade e heterogeneidade limitadas;Pouca portabilidade por falta de padronizao.Middlewares Orientados a ObjetosEvoluo dos middlewares procedurais;Interao por invocao de mtodos;Comunicao tipicamente sncrona;IDLs (Interface Description Language ou Linguagem de Descrio de Interface) para descrever servios.

Middlewares Orientados a ObjetosVantagens:Grande suporte a heterogeneidade;Serializao e deserializao (Marshalling e unmarshalling) automticos;Versatilidade.Desvantagens:Pouca Escalabilidade.Middlewares ExemplosTransacionais:Tuxedo (BEA);CICS (IBM);Encina (Transarc).Orientados a Mensagens:MQSeries (IBM);JMS (Sun).Orientados a Objetos:CORBA (OMG);COM (Microsoft).Sistemas Cliente-ServidorSDs em geral so cliente-servidor.

necessria uma separao clara entre a apresentao de informaes e as computaes que criam e processam essas informaes.

A arquitetura deve ser projetada de forma a ser estruturada em vrias camadas lgicas, com interfaces claras entre essas camadas.Sistemas Cliente-ServidorCamadas:

Uma camada para apresentar informaes para o usurio e gerenciamento de toda a interao com o usurio;

Uma camada que gerencia os dados que so passados de e para o cliente;Sistemas Cliente-ServidorUma camada de processamento de aplicao que que implementa a lgica de aplicao e fornece a funcionalidade necessria para os usurios;

Uma camada de banco de dados que armazena os dados e fornece servios de gerenciamento de transaes etc.Sistemas Cliente-Servidor

Fonte: Sommerville (2011)ArquiteturaMestre-Escravo usada em sistemas de tempo real em que necessria a garantia dos tempos de resposta de interao.

Costumam haver processadores separados associados aquisio de dados do ambiente do sistema, processamento de dados, de gerenciamento de atuadores e computao.ArquiteturaMestre-EscravoO processo 'mestre' geralmente responsvel pelo processamento, coordenao e comunicaes e controla os processos 'escravos'.

Os processos 'escravos' so dedicados a aes especficas, tais como a aquisio de dados de um vetor de sensores.

ArquiteturaMestre-Escravo usada em situaes em que:Seja necessrio prever o processamento distribudo;O processamento pode ser facilmente localizado para processadores escravos. Processadores escravos podem ser usados para operaes computacionalmente intensivas como processamento de sinais e o gerenciamento de equipamentos controlados pelo sistema.ArquiteturaMestre-Escravo

Fonte: Sommerville (2011)Arquitetura Cliente-Servidor de Duas Camadas a forma mais simples dessa arquitetura.

O sistema implementado como um nico servidor lgico e um nmero indefinido de clientes que usam esse servidor.

Possui dois modelos:Arquitetura Cliente-Servidor de Duas CamadasCliente-magro, em que somente a camada de apresentao implementada no cliente;

Todas as outras camadas so implementadas em um servidor:

Gerenciamento de dados;Processamento de aplicao;Banco de dados.

Arquitetura Cliente-Servidor de Duas CamadasCliente-gordo, em que parte ou todo o processamento da aplicao realizado no cliente.

As funes de gerenciamento de dados e banco de dados so implementadas no servidor.

Arquitetura Cliente-Servidor de Duas CamadasVantagem do cliente-magro:

Simplicidade em gerenciar os clientes;

Podia ser problemtica quando havia um grande nmero de clientes, sendo difcil e caro instalar um novo software em todos eles;

Se um navegador web for usado como cliente, no necessrio instalar qualquer software.Arquitetura Cliente-Servidor de Duas Camadas

Fonte: Sommerville (2011)Arquitetura Cliente-Servidor de Duas CamadasDesvantagem do modelo cliente-magro:

Colocar uma carga pesada de processamento no servidor e na rede;

Isso pode levar gerao de trfego significativo entre o cliente e o servidor. Arquitetura Cliente-Servidor de Duas CamadasO modelo cliente-gordo faz uso do poder de processamento disponvel no computador que executa o software cliente;

Distribui parte ou todo o processamento de aplicao e a apresentao para o cliente;

O servidor gerencia as transaes do banco de dados.Arquitetura Cliente-Servidor de Duas CamadasA desvantagem requerer gerenciamento de sistema adicional para implantar e manter o software no computador cliente.

Mais processamento delegado ao cliente j que o processamento da aplicao executado localmente.

Arquitetura Cliente-Servidor de Duas CamadasMais complexo do que um modelo cliente-magro, especialmente no gerenciamento.

Novas verses da aplicao precisam ser instaladas em todos os clientes.

Arquitetura cliente-servidor multicamadasNesta arquitetura, as diferentes camadas do sistema so processos separados que podem ser executados em diferentes processadores.

Isso evita problemas com escalabilidade e desempenho, caso um modelo cliente-magro de duas camadas seja escolhido;

Ou problemas de gerenciamento do sistema caso um modelo cliente-gordo for usado.

Arquitetura cliente-servidor multicamadas

Fonte: Sommerville (2011)Arquitetura de Componentes DistribudosEm uma arquitetura de componentes distribudos no existe distino entre clientes e servidores.

Cada entidade distribuvel um componente que fornece servios para outros componentes e recebe servios de outros componentes.

Arquitetura de Componentes DistribudosA comunicao dos componentes se d por meio de um sistema de middleware.

No entanto, arquiteturas de componentes distribudos so mais complexas de se projetar do que sistemas cliente-servidor.Arquitetura de Componentes Distribudos

Fonte: Sommerville (2011)Arquitetura de Componentes DistribudosVantagens:

O projetista pode atrasar decises sobre onde e como os servios devero ser prestados. Os componentes fornecedor de servios podem executar em qualquer n da rede. No necessrio decidir previamente se um servio parte de uma camada de gerenciamento de dados ou uma camada de aplicao, por exemplo.

Arquitetura de Componentes Distribudos uma arquitetura de sistemas muito aberta.

Permite a adio de novos recursos conforme necessrio;

Novos servios de sistema podem ser adicionados facilmente sem grandes perturbaes ao sistema existente.

Arquitetura de Componentes DistribudosO sistema flexvel e escalvel.

Novos componentes ou componentes replicados podem ser adicionados quando a carga sobre o sistema aumenta, sem interromper as outras partes do sistema.

possvel reconfigurar o sistema dinamicamente com componentes migrando atravs da rede conforme necessrio.

Arquitetura de Componentes DistribudosDesvantagens:

Esta arquitetura mais complexa para projetar que sistemas cliente-servidor.

H middlewares diferentes e incompatveis. Esses middlewares so complexos e aumentam a complexidade geral do sistema distribudo.Arquitetura Ponto-a-ponto(p2p peer-to-peer)So sistemas descentralizados em que os processamentos podem ser realizados por qualquer n na rede.

O sistema projetado para tirar proveito do poder computacional e do armazenamento de um grande nmero de computadores em rede.

Arquitetura Ponto-a-ponto

Fonte: Sommerville (2011)Arquitetura Ponto-a-ponto(p2p peer-to-peer)Como no possvel que todos os ns estejam conectados entre si, os ns so organizados em localidades com alguns ns atuando como pontes para outras localidades de ns.Arquitetura Ponto-a-ponto(p2p peer-to-peer)Uma das vantagens dessa arquitetura que ela altamente redundante e tolerante a defeitos e desconexo de ns da rede.

No entanto, as desvantagens so que muitos ns diferentes podem processar a mesma pesquisa e ocorrer um overhead significativo em pontos replicados.Padres de ProjetoUm padro descreve um problema e o ncleo da sua soluo, de maneira que se possa usar essa soluo quantas vezes for preciso e aplic-la de formas diferentes.

Costuma conter descries de objetos e classes que se comunicam e que precisam ser personalizadas para resolver um problema geral de projeto num contexto particular.Padres de ProjetoUm padro tem quatro elementos essenciais:

Nome: Usado para descrever um problema de projeto, suas solues e consequncias.

Problema: Descreve em que situao aplic-lo. Explica o problema e seu contexto.Pode incluir uma lista de condies que devem ser satisfeitas para justificar sua aplicao.

Padres de ProjetoSoluo: Descreve os elementos que compem o padro, seus relacionamentos, suas responsabilidades e colaboraes.

No descreve um projeto concreto ou uma implementao especfica porque um padro deve poder ser aplicado em diversas situaes.Fornece uma descrio abstrata de um problema de projeto e de como um arranjo geral de elementos (classes e objetos) o resolve.Padres de ProjetoConsequncias:

Descrevem as vantagens e desvantagens da aplicao do padro.

So teis para avaliar alternativas de projetos e para compreender os custos e benefcios da aplicao do padro.Padres de CriaoAbstraem o processo de instanciao.Ajudam a tornar um sistema independente de como seus objetos so criados, compostos e representados.Um padro de criao de classe usa herana para variar a classe que instanciada.Um padro de criao de objeto delegar a instanciao para outro objeto.FactoryInteno:

Definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar.

Permite adiar a instanciao para as subclasses.

InterfaceUma interface como um contrato entre a classe e o mundo exterior. Quando uma classe implementa uma interface, se compromete a fornecer o comportamento publicado por esta interface.As interfaces so formadas pela declarao de um ou mais mtodos que no possuem corpo.As operaes especficas para cada um desses mtodos so realizadas pela classe que implementa. FactoryAplicabilidade: Deve-se us-lo quando:

Uma classe no pode antecipar a classe de objetos que deve criar;

Uma classe quer que suas subclasses especifiquem os objetos que criam;

Uma classe delega responsabilidade para uma dentre vrias subclasses auxiliares.

FactoryParticipantes:

Product: Define a interface de objetos que o mtodo Factory cria.

ConcreteProduct: Implementa a interface de Product.

FactoryCreator: Declara o mtodo Factory, o qual retorna um objeto do tipo Product.

ConcreteCreator: Redefine o mtodo Factory para retornar a uma instncia de um ConcreteProduct.FactoryEstrutura

FactoryColaboraes:

Creator depende das suas subclasses para definir o mtodo fbrica de maneira que retorne uma instncia do ConcreteProduct apropriado.FactoryConsequncias:

Elimina a necessidade de anexar classes especficas das aplicaes no cdigo. O cdigo lida somente com a interface de Product.

Uma possvel desvantagem que os clientes podem ter que fornecer subclasses da classe Creator somente para criar um objeto ConcreteProduct em particular.

FactoryExemplo Prtico SimplesDeve-se trabalhar com um conjunto de carros, cada um de uma determinada fbrica.

Palio FiatGol VolkswagenCelta ChevroletFiesta Ford

Ser necessrio manipular este conjunto de carros em diversas operaes.Factory

FactoryExerccioAplique o padro Factory de maneira a criar um pequeno dicionrio em que se possa traduzir Bom dia em vrios idiomas:

Ingls Good Morning;Francs Bon Jour;Alemo Guten Tag;Italiano Buon Giorno;Espanhol Buenos Dias.

Abstract FactoryInteno: Fornecer uma interface para criao de famlias de objetos relacionados ou dependentes sem especificar suas classes concretas.

Aplicabilidade: Deve-se us-lo quando:Um sistema deve ser independente de como seus produtos so criados, compostos ou representados;

Abstract FactoryUm sistema deve ser configurado como um produto de uma famlia de mltiplos produtos;

Uma famlia de objetos-produto for projetada para ser usada em conjunto, e preciso garantir esta restrio;

Deseja-se fornecer uma biblioteca de classes de produtos e se quer revelar somente suas interfaces, no suas implementaes.Abstract FactoryParticipantesAbstractFactory: Declara uma interface para operaes que criam objetos-produto abstratos;ConcreteFactory: Implementa as operaes que criam objetos-produtos concretos;AbstractProduct: Declara uma interface para um tipo de objeto-produto;ConcreteProduct: Define um objeto-produto a ser criado pela fbrica concreta correspondente Implementa a interface de AbstractProduct.Client: Usa somente interfaces declaradas pelas classes AbstractFactory e AbstractProduct.Abstract FactoryEstrutura

Abstract FactoryColaboraesNormalmente uma nica instncia de uma classe ConcreteFactory criada em tempo de execuo.

Essa fbrica concreta cria objetos-produto que tm uma implementao particular.

AbstractFactory adia a criao dos objetos-produto para as suas subclasses ConcreteFactory.Abstract FactoryExemplo Prtico SimplesDeve-se desenvolver um software que manipule um conjunto de carros, porm necessrio agrup-los em conjuntos com caractersticas semelhantes.Sedan:Siena FiatFiesta Sedan FordPopular:Palio FiatFiesta FordAbstract FactoryExemplo Prtico Simples

Abstract FactoryExerccioCrie um programa que utilize o padro Abstract Factory para apresentar grupos de animais:Carnvoro:Ona Mamfero;Jacar Rptil;

Herbvoro:Capivara Mamfero;Jabuti Rptil; Abstract FactoryConsequnciasIsola as classes concretas: Ajuda a controlar as classes de objetos criadas por uma aplicao.Isola os clientes das classes de implementao, j que a fbrica encapsula a responsabilidade e o processo de criar objetos-produto;.Os clientes manipulam as instncias atravs das suas interfaces abstratas.Nomes de classes-produto ficam isolados na implementao da fbrica concreta; eles no aparecem no cdigo do cliente.Abstract FactoryConsequnciasTorna fcil a troca de famlias de produtos: A classe de uma fbrica concreta aparece apenas uma vez numa aplicao.Facilita mudar a fbrica concreta que uma aplicao usa.Ela pode usar diferentes configuraes de produtos trocando a fbrica concreta.Uma vez que a fbrica abstrata cria uma famlia completa de produtos, toda a famlia muda uma s vez.

Abstract FactoryConsequnciasPromove a harmonia entre produtos:

Quando objetos-produto numa famlia so projetados para trabalharem juntos, importante que uma aplicao use objetos de somente uma famlia de cada vez.Abstract FactoryConsequncias difcil suportar novos tipos de produtos:Estender fbricas abstratas para produzir novos tipos de produtos pode no ser fcil.Isso se deve ao fato de que a interface de AbstractFactory fixa o conjunto de produtos que podem ser criados.Suportar novos tipos de produto exige estender a interface da fbrica, o que envolve mudar a classe AbstractFactory e todas as suas subclasses.SingletonInteno:

Garantir que uma classe tenha somente uma instncia e fornecer um ponto global de acesso para a mesma.

SingletonAplicabilidade:Usa-se o padro Singleton quando:

For preciso haver apenas uma instncia de uma classe, e essa instncia tiver que dar acesso aos clientes atravs de um ponto bem conhecido.A nica instncia tiver de ser extensvel atravs de subclasses, possibilitando aos clientes usar uma instncia estendida sem alterar o seu cdigo.

SingletonParticipantesSingleton: Define uma operao Instance que permite aos clientes acessarem sua nica instncia.

Instance uma operao de classe.

Pode ser responsvel pela criao da sua prpria instncia nica.

SingletonEstrutura

SingletonExemplo Prtico SimplesTomemos novamente o exemplo da fbrica de carros do padroFactory Method. A classe fbrica centraliza a criao de objetos carro. Vamos utilizar o padro Singleton de forma a apresentar um contador que armazene a quantidade de carros de uma determinada marca que foram vendidos, porm deve haver somente uma instncia da classe Fbrica para impedir que os contadores sejam zerados. SingletonExerccioMescle o exemplo do padro Factory com o padro Singleton de maneira que seja dada opo ao usurio para escolher qual modelo deseja fabricar e que oferea a opo de relatrio que apresente a quantidade de total de cada modelo fabricado. SingletonConsequnciasAcesso controlado instncia nica: Como a classe Singleton encapsula a sua nica instncia, possui controle total sobre como e quando os clientes a acessam.

Espao de nomes reduzido: Este padro representa uma melhoria em relao ao uso de variveis globais que armazenam instncias nicas. SingletonConsequnciasPermite um refinamento de operaes e da representao:

A classe Singleton pode ter subclasses e fcil configurar uma aplicao com uma instncia dessa classe estendida.

Builder

Inteno:

Separar a construo de um objeto complexo da sua representao de modo que o mesmo processo de construo possa criar diferentes representaes.

BuilderAplicabilidadeDeve-se us-lo quando:

O algoritmo para criao de um objeto complexo deve ser independente das partes que compem o objeto e de como elas so montadas.

O projeto de construo deve permitir diferentes representaes para o objeto que construdo.

Builder: Especifica uma interface abstrata para criao de partes de um objeto-produto;

ConcreteBuilder:

Constri e monta partes do produto pela implementao da interface de Builder; Define e mantm a representao que cria; Fornece uma interface para recuperao do produto.

BuilderParticipantesBuilderParticipantesDirector: Constri um objeto usando a interface builder.

Product: Representa o objeto complexo em construo. ConcreteBuilder constri a representao interna do produto e define o processo pelo qual ele montado;Inclui classes que definem as partes constituintes, inclusive as interfaces para a montagem das partes no resultado final.Builder

BuilderColaboraesO cliente cria o objeto Director e o configura com o objeto Builder desejado.

Director notifica o construtor sempre que uma parte do produto deve ser construda.

Builder trata solicitaes do diretor e acrescenta partes ao produto.

O cliente recupera o produto do construtor.BuilderExemplo Prtico SimplesSistema de Venda de Carros:

necessrio modelar um sistema de venda de carros para uma concessionria.

Deseja-se que o sistema seja flexvel, para adio de novos carros, e de fcil manuteno.

Exemplo Prtico Simples

BuilderConsequncias Permite variar a representao interna de um produto:O objeto Builder fornece ao diretor uma interface abstrata para a construo do produto.A interface permite ao construtor ocultar a representao e a estrutura interna do produto.Tambm oculta como o produto montado. J que o produto construdo atravs de uma interface abstrata, s preciso definir um novo tipo de construtor para mudar sua representao interna.

BuilderConsequncias Isola o cdigo para construo e representao:

O padro Builder melhora a modularidade pelo encapsulamento da forma como um objeto complexo construdo e representado.

Os clientes nada necessitam saber sobre as classes que definem a estrutura interna do produto; tais classes no aparecem na interface do Builder.BuilderConsequncias Cada ConcreteBuilder contm todo o cdigo para criar e montar um tipo de produto especfico.

O cdigo escrito somente uma vez; ento, diferentes Directors podem reutiliz-lo para construir variantes de Product com o mesmo conjunto de partes.BuilderConsequncias Oferece um controle mais fino sobre o processo de construo:

Ao contrrio de padres de criao que constroem produtos de uma s vez, o Builder constri o produto passo a passo sob o controle do diretor.BuilderConsequncias Somente quando o produto est terminado o diretor o recupera do construtor.

Da a interface de Builder refletir o processo de construo do produto mais explicitamente do que outros padres de criao.

Isso d um controle mais fino sobre o processo de construo e, consequentemente, da estrutura interna do produto resultante.PrototypeInteno:

Especificar os tipos de objetos a serem criados usando uma instncia-prottipo e criar novos objetos pela cpia desse prottipo.

PrototypeAplicabilidadeQuando um sistema precisar ser independente de como os seus produtos so criados, compostos e representados;

Quando as classes a instanciar forem especificadas em tempo de execuo;PrototypeAplicabilidadePara evitar a construo de uma hierarquia de classes de fbricas paralelas hierarquia de classes de produto;

Quando as instncias de uma classe puderem ter uma dentre poucas combinaes diferentes de estados.PrototypeParticipantesPrototype: Declara uma interface para clonar a si prprio;ConcretePrototype: Implementa uma operao para clonar a si prprio;Client: Cria um novo objeto solicitando a um prottipo que clone a si prprio.Colaboraes:Um cliente solicita a um prottipo que este clone a si prprio.PrototypeEstrutura

Prototype Exemplo Prtico SimplesO programa deve permitir instanciar uma lista de carros que o cliente precisa utilizar, mas que s sero conhecidos em tempo de execuo.

Apresentaremos a seguir como solucionar esse problema aplicando o padro Prototype.

Prototype

Prototype ExerccioCrie um programa utilizando o padro Prototype para instanciar espcies de animais.Deve ser possvel instanciar mamferos e rpteis tanto carnvoros como herbvoros.MamferosOna Carnvoros;Capivara Herbvoros;Rpteis:Jacar Carnvoros;Jabuti Herbvoros.Prototype ConsequnciasOculta as classes de produtos concretas do cliente, reduzindo o nmero de nomes que os clientes necessitam saber;

Permite a um cliente trabalhar com classes especficas de uma aplicao sem necessidade de modificao. Prototype ConsequnciasAcrescenta e remove produtos em tempo de execuo permite incorporar uma nova classe concreta de produto a um sistema, registrando uma instncia prottipo com o cliente.

Isso um pouco mais flexvel do que outros padres de criao, porque o cliente pode instalar e remover prottipos em tempo de execuo.Prototype ConsequnciasEspecifica novos objetos pela variao de valores.

Sistemas altamente dinmicos permitem definir novos comportamentos atravs da composio de objetos pela especificao de valores para as variveis de um objeto e no pela definio de novas classes.Prototype ConsequnciasEsse tipo de projeto permite aos usurios definir novas classes sem ter que programar.

Clonar um prottipo semelhante a instanciar uma classe.

O padro Prototype pode reduzir grandemente o nmero de classes que um sistema necessita.Prototype ConsequnciasEspecifica novos objetos pela variao da estrutura: O padro Prototype permite a construo de objetos com partes e subpartes.

Reduz o nmero de sub-classes: Permite clonar um prottipo em vez de pedir a um mtodo fbrica para construir um novo objeto. Assim no necessrio uma hierarquia de classes Creator.

Padres EstruturaisPreocupam-se com a forma como classes e objetos so compostos para formar estruturas maiores.

Os padres estruturais de classes utilizam a herana para compor interfaces ou implementaes.

Descrevem maneiras de compor objetos para obter novas funcionalidades.AdapterInteno:

Converter a interface de uma classe em outra interface, esperada pelos clientes.

Permite que classes com interfaces incompatveis trabalhem em conjunto, o que, de outra forma, seria impossvel.

AdapterAplicabilidadeQuando se quiser usar uma classe existente, mas sua interface no corresponde interface de que se necessita.Deseja-se criar uma classe reutilizvel que coopere com classes no-relacionadas ou no-previstas classes que no necessariamente tenham interfaces compatveis.For preciso usar vrias subclasses existentes, porm for impraticvel adaptar essas interfaces criando subclasses para cada uma.AdapterParticipantesTarget: Define a interface especfica do domnio que Client usa.Client: Colabora com objetos compatveis com a interface de Target.Adaptee: Define uma interface existente que necessita ser adaptada.Adapter: Adapta a interface do Adaptee interface de Target.AdapterEstrutura (a nvel de classe)

AdapterEstrutura (a nvel de objeto)

AdapterColaboraes:

Os clientes chamam operaes em uma instncia de Adapter.

Por sua vez, o adapter chama operaes de Adaptee que executam a solicitao.AdapterExemplo Prtico SimplesApresentaremos a seguir um pequeno programa que representar uma tomada de dois pinos e uma tomada de trs pinos, usando a classe adaptadora para inserir a tomada de dois pinos na de trs pinos.AdapterExemplo Prtico Simples

AdapterExerccioH uma interfaceMediaPlayere uma classe concreta, AudioPlayerimplementando a MediaPlayer.AudioPlayertoca arquivos mp3.H outra interface,AdvancedMediaPlayer, e duas classes concretas, VlcPlayer e Mp4Player implementando a interface.Deseja-se que AudioPlayertoque outros formatos. Para isso necessrio criar um adaptador que implemente a interface MediaPlayer e utilize objetos AdvancedMediaPlayer.AdapterExerccio

AdapterConsequnciasOs adaptadores de classes e de objetos tm diferentes solues de compromisso.

Um adaptador de classe:

Adapta Adaptee a Target atravs do uso efetivo de uma classe Adapter concreta. Permite a Adapter substituir algum comportamento do Adaptee, uma vez que Adapter uma subclasse de Adaptee;AdapterConsequnciasUm adaptador de objeto:Permite a um nico Adapter trabalhar com muitos Adaptees. O Adapter tambm pode acrescentar funcionalidade a todos os Adaptees de uma s vez;Torna mais difcil redefinir um comportamento de Adaptee. Ele exigir a criao de subclasses de Adaptee e far com que Adapter referencie a subclasse ao invs do Adaptee em si.AdapterConsequnciasUm adaptador de objeto:Permite a um nico Adapter trabalhar com muitos Adaptees. O Adapter tambm pode acrescentar funcionalidade a todos os Adaptees de uma s vez;Torna mais difcil redefinir um comportamento de Adaptee. Ele exigir a criao de subclasses de Adaptee e far com que Adapter referencie a subclasse ao invs do Adaptee em si.BridgeInteno:

Desacoplar uma abstrao da sua implementao, de modo que as duas possam variar independentemente.

BridgeAplicabilidadeQuando deseja-se evitar um vnculo permanente entre uma abstrao e sua implementao. Isso pode ocorrer quando a implementao deve ser selecionada ou alterada em tempo de execuo;Tanto as abstraes como suas implementaes tiverem de ser extensveis por meio de subclasses. Neste caso, o padro Bridge permite combinar as diferentes abstraes e implementaes e estend-las independentemente;BridgeAplicabilidadeMudanas na implementao de uma abstrao no puderem ter impacto sobre os clientes, ou seja, quando o cdigo dos mesmos no puder ser recompilado.Tiver uma proliferao de classes e subclasses. Essa hierarquia de classes indica necessidade de separar um objeto em duas partes.Desejar compartilhar uma implementao entre mltiplos objetos e este fato deve estar oculto do cliente.BridgeParticipantesAbstraction: define a interface da abstrao e mantm uma referncia para um objeto do tipo Implementor;RedefinedAbstraction: estende a interface definida por Abstraction;Implementor: define a interface para as classes de implementao;ConcreteImplementor: implementa a interface de Implementor e define sua implementao concreta.BridgeEstrutura

BridgeColaboraes:

Abstraction repassa as solicitaes dos clientes para o seu objeto Implementor.BridgeExemplo necessrio fazer um programa que v funcionar em vrias plataformas, como Windows, Linux, Mac, etc.

O programa far uso de diversas abstraes de janelas grficas, por exemplo, janela de dilogo, janela de aviso, janela de erro, etc.BridgeExemplo

BridgeExerccioDesenvolva um programa usando o padro Bridge que permita produzir em uma oficina tanto carros como motocicletas.BridgeExerccio

BridgeConsequnciasDesacopla a interface da implementao: uma implementao no fica permanentemente presa a uma interface. A implementao de uma abstrao pode ser configurada em tempo de execuo. Extensibilidade melhorada: pode-se estender as hierarquias de Abstraction e Implementor independentemente.Ocultao de detalhes de implementao dos clientes, como o compartilhamento de objetos Implementor.CompositeInteno:

Compor objetos em estruturas de rvore para representarem hierarquias partes-todo.

Permite aos clientes tratarem de maneira uniforme objetos individuais e composies de objetos.CompositeAplicabilidadeUse o padro Composite quando:

Quiser representar hierarquias partes-todo de objetos;

Quiser que os clientes sejam capazes de ignorar a diferena entre composies de objetos e objetos individuais. Os clientes trataro todos os objetos na estrutura composta de maneira uniforme.CompositeParticipantesComponent:Declara a interface para os objetos na composio;Implementa comportamento-padro para a interface comum a todas as classes;Declara uma interface para acessar e gerenciar os seus componentes-filhos;Opcionalmente define uma interface para acessar o pai de um componente na estrutura recursiva e a implementa.CompositeParticipantesLeaf:

Representa objetos-folha na composio. Uma folha no tem filhos;

Define comportamento para objetos primitivos na composio.CompositeParticipantesComposite:Define comportamento para componentes que tm filhos;Armazena os componentes-filho;Implementa as operaes relacionadas com os filhos presentes na interface de Component.Client:Manipula objetos na composio atravs da interface de Component.CompositeEstrutura

CompositeColaboraesOs clientes usam a interface da classe Component para interagir com os objetos na estrutura composta.Se o receptor uma Leaf, ento a solicitao tratada diretamente.Se o receptor um Composite, ele normalmente repassa as solicitaes para os seus componentes-filhos, executando operaes adicionais antes e/ou depois do repasse.CompositeExemplo Prtico SimplesApresentaremos a seguir um programa de gerenciamento de arquivos, como vdeos, textos e imagens e arquivos do tipo pasta, que armazenam outros arquivos utilizando o padro Composite. CompositeExemplo Prtico Simples

CompositeExerccioDesenvolva um programa utilizando o padro Composite, onde haja uma interface geral contendo os mtodos de saudao e despedida, uma classe que implemente esta interface chamada Folha e que contenha um atributo nome, e uma classe chamada Composio que tambm implemente a interface e possa ser composta por muitas folhas. Os objetos desta ltima classe devem ser capazes de adicionar ou remover folhas, listar todas as folhas que os compem ou pesquisar uma folha especfica.CompositeExerccio

CompositeConsequnciasDefine hierarquias de classe que consistem de objetos primitivos e objetos compostos. Os objetos primitivos podem compor objetos mais complexos. Sempre que o cdigo do cliente esperar um objeto primitivo, ele tambm poder aceitar um objeto composto.Torna o cliente simples. Os clientes podem tratar estruturas compostas e objetos individuais de maneira uniforme. Os clientes no sabem se esto tratando com uma folha ou um componente composto.CompositeConsequnciasTorna mais fcil acrescentar novas espcies de componentes. Novas estruturas existentes, Composite ou Leaf funcionam com as estruturas existentes e o cdigo do cliente. Os clientes no precisam ser alterados para tratar novas classes Component.Pode tornar o projeto excessivamente genrico. A desvantagem de facilitar o acrscimo de novos componentes que isso torna mais difcil restringir os componentes de uma composio.DecoratorInteno:

Dinamicamente, agregar responsabilidades adicionais a um objeto.

Os Decorators fornecem uma alternativa flexvel ao uso de subclasses para extenso de funcionalidades.DecoratorParticipantesComponent: Define a interface para objetos que podem ter responsabilidades acrescentadas aos mesmos dinamicamente.ConcreteComponent: Define um objeto para o qual responsabilidades adicionais podem ser atribudas.Decorator: Mantm uma referncia para um objeto Component e define uma interface que segue a interface de Component.ConcreteDecorator: Acrescenta responsabilidades ao componente.DecoratorEstrutura

DecoratorColaboraesDecorator repassa solicitaes para o seu objeto Component.

Opcionalmente, ele pode executar operaes adicionais antes e depois de repassar a solicitao.DecoratorExemplo bsico simplesIremos apresentar um pequeno programa utilizando o padro Decorator, que permite decorar um sorvete simples com nozes e confeitos de chocolate.DecoratorExemplo bsico simples

DecoratorAplicabilidadeUsa-se quando:Para acrescentar responsabilidades a objetos individuais de forma dinmica e transparente, ou seja, sem afetar outros objetos;Para responsabilidades que podem ser removidas;Quando a extenso atravs do uso de subclasses no prtica (exploso de subclasses).DecoratorExerccioDesenvolvar um programa utilizando o padro Decorator que permite montar carros bsicos, mas que tambm permita decor-los com caractersticas de carros esporte ou carros de luxo.DecoratorExerccio

DecoratorConsequnciasMaior flexibilidade do que a herana esttica: fornece uma maneira mais flexvel de acrescentar responsabilidades a objetos do que pode ser feito com herana.

Responsabilidades podem ser acrescentadas e removidas em tempo de execuo associando-as e disassociando-as de um objeto. Tambm torna fcil acrescentar uma propriedade duas vezes.DecoratorConsequnciasEvita classes sobrecarregadas de caractersticas na parte superior da hierarquia: oferece uma abordagem do tipo use quando for necessrio para adio de responsabilidades. Ao invs de tentar suportar todas as caractersticas previsveis em uma classe complexa e customizada, pode-se definir uma classe simples e acrescentar funcionalidade de modo incremental com objetos Decorator. A funcionalidade necessria pode ser composta a partir de peas simples.DecoratorConsequnciasUm decorador e o seu componente no so idnticos: um decorador funciona como um envoltrio transparente.

Porm, do ponto de vista da identidade de um objeto, um componente decorado no idntico ao prprio componente. Da no poder depender da identidade de objetos quando voc utiliza decoradores.DecoratorConsequnciasGrande quantidade de pequenos objetos: um projeto que usa o Decorator frequentemente resulta em sistemas compostos por uma grande quantidade de pequenos objetos parecidos.Os objetos diferem somente na maneira como so interconectados, e no nas suas classes ou no valor de suas variveis. Embora esses sistemas sejam fceis de customizar por quem os compreende, podem ser difceis de aprender e depurar.FaadeIntenoFornecer uma interface unificada para um conjunto de interfaces em um subsistema.

Define uma interface de nvel mais alto que torna o subsistema mais fcil de ser usado.FaadeParticipantesFaade: Conhece quais classes do subsistema so responsveis pelo atendimento de uma solicitao.Delega solicitaes de clientes a objetos apropriados do subsistema.Classes de subsistema:Implementam a funcionalidade do subsistema;Encarregam-se do trabalho atribudo a elas pelo objeto Faade.FaadeEstrutura

FaadeAplicabilidadeUsa-se quando:Deseja-se fornecer uma interface simples para um subsistema complexo. Uma fachada pode fornecer uma viso simples do sistema, que boa o suficiente para a maioria dos clientes.Existirem muitas dependncias entre clientes e classes de implementao de uma abstrao.Se desejar estruturar seus subsistemas em camadas. Usa-se uma fachada para definir o ponto de entrada para cada nvel de subsistema.FaadeColaboraesOs clientes se comunicam com um subsistema atravs do envio de solicitaes para Faade, que as repassa para o(s) objeto(s) apropriado(s) do subsistema.Embora os objetos do subsistema executem o trabalho real, a faade pode precisar efetuar trabalho prprio para traduzir a sua interface para as interfaces de subsistemas.Os clientes que usam a faade no acessam os objetos do subsistema diretamente.FaadeExemplo Prtico SimplesApresentaremos um programa utilizando o padro Faade que realize ajustes em todos os subsistemas que sero utilizados por um jogo de computador, ou seja, subsistema de video, subsistema de udio e subsistema de entrada.FaadeExerccioDesenvolva um programa utilizando o padro Faade que permita desenhar diversas formas, tais como crculos, quadrados e retngulos.FaadeConsequnciasIsola os clientes dos componentes do subsistema, reduzindo o nmero de objetos com que os clientes tm de lidar e tornando o subsistema mais fcil de usar.Promove um acoplamento fraco entre o subsistema e seus clientes, permitindo variar os componentes do subsistema sem afetar seus clientes.No impede as aplicaes de utilizarem as classes do subsistema caso necessitem.FlyweightInteno:

Usar compartilhamento para suportar eficientemente grandes quantidades de objetos de granularidade fina.FlyweightParticipantesFlyweight: Declara uma interface atravs da qual flyweights podem receber e atuar sobre estados extrnsecos.ConcreteFlyweight: Implementa a interface de Flyweight e acrescenta armazenamento para estados intrnsecos, se houver. Um objeto desse tipo deve ser compartilhvel. Qualquer estado que ele armazene deve ser intrnseco, ou seja, independente do contexto do objeto ConcreteFlyweight.FlyweightParticipantesUnsharedConcreteFlyweight: Nem todas as subclasses de Flyweight necessitam ser compartilhadas. A interface de Flyweight habilita o compartilhamento; ela no o fora ou o garante. comum para objetos desse tipo no compartilhar objetos ConcreteFlyweight como filhos em algum nvel da estrutura de objetos de Flyweight.FlyweightParticipantesFlyweightFactory: Cria e gerencia objetos flyweight;Garante que os flyweights sejam compartilhados apropriadamente. Quando um cliente solicita um flyweight, um objeto FlyweightFactory fornece uma instncia existente ou cria uma, se nenhuma existir.Client: Mantm uma referncia para flyweight(s); Computa ou armazena o estado extrnseco do flyweight(s).FlyweightEstrutura

FlyweightAplicabilidadeAplica-se quando estas condies forem verdadeiras:

Uma aplicao utiliza um grande nmero de objetos;Os custos de armazenamento so altos devido grande quantidade de objetos;A maioria dos estados de objetos pode ser tornada extrnseca;

FlyweightAplicabilidadeMuitos grupos de objetos podem ser substitudos por relativamente poucos objetos compartilhados, uma vez que estados extrnsecos so removidos;A aplicao no depende da identidade dos objetos. Uma vez que objetos Flyweights podem ser compartilhados, testes de identidade produziro o valor verdadeiro para objetos conceitualmente distintos.FlyweightColaboraesO estado que um flyweight necessita para funcionar deve ser caracterizado como intrnseco ou como extrnseco. Um estado intrnseco armazenado no objeto ConcreteFlyweight; Um estado extrnseco armazenado ou computado por objetos Client. Os clientes passam este estado para o Flyweight quando invocam suas operaes.FlyweightColaboraesOs clientes no deveriam instanciar ConcreteFlyweights diretamente.

Eles devem obter objetos ConcreteFlyweight exclusivamente do objeto FlyweightFactory para garantir que sejam compartilhados de forma apropriada.FlyweightExemploNo desenvolvimento de jogos so utilizadas vrias imagens. Elas representam as entidades que compe o jogo, por exemplo, cenrios, jogadores, inimigos, entre outros. Ao criar classes que representam estas entidades, necessrio vincular a elas um conjunto de imagens, que representam as animaes.Para evitar duplicao de informao vamos aplicar o padro Flyweight nesse problema.FlyweightExemplo

FlyweightExerccioDesenvolva um programa onde seja aplicado o padro Flyweight em uma casa de chs, onde os clientes de cada mesa solicitam chs de determinados sabores. Ao final apresentar todos os pedidos de ch por cada mesa e o total geral de sabores pedidos.FlyweightExerccio

FlyweightConsequnciasPode introduzir custos de tempo de execuo associados com a transferncia, procura e/ou computao de estados extrnsecos.

Tais custos so compensados pelas economias de espao, as quais aumentam medida que mais flyweights so compartilhados.FlyweightConsequnciasAs economias de armazenamento so uma funo de vrios fatores:

A reduo do nmero total de instncias obtida com o compartilhamento;A quantidade de estados intrnsecos por objeto;Se o estado extrnseco computado ou armazenado.FlyweightConsequnciasQuanto mais flyweights so compartilhados, maior a economia de armazenagem. A economia aumenta com a quantidade de estados compartilhados.

As maiores economias ocorrem quando os objetos usam quantidades substanciais tanto de estados intrnsecos como de estados extrnsecos, e os estados extrnsecos podem ser melhor computados do que armazenados.FlyweightConsequnciasO compartilhamento reduz o custo dos estados intrnsecos e se troca estados extrnsecos por tempo de computao.

ProxyInteno:

Fornece um substituto ou marcador da localizao de outro objeto para controlar o acesso a esse objeto.ProxyParticipantesProxy: Mantm uma referncia que permite ao proxy acessar o objeto real (real subject). O proxy pode referenciar um Subject se as interfaces de RealSubject e Subject forem as mesmas.Fornece uma interface idntica a de Subject, de modo que o proxy possa substituir o objeto real.Controla o acesso ao objeto real e pode ser responsvel pela sua criao e excluso.ProxyParticipantesOutras responsabilidades dependem do tipo de Proxy:Remote proxies so responsveis pela codificao de uma solicitao e de seus argumentos, bem como pelo envio da solicitao codificada para o objeto real num espao de endereamento diferente;Virtual proxies podem manter informaes adicionais sobre o objeto real, de maneira que possam postergar o acesso ao mesmo.

ProxyParticipantesProtection proxies verificam se quem chama tem as permisses de acesso requeridas para executar uma consulta.Subject: Define uma interface comum para RealSubject e Proxy, de maneira que um Proxy possa ser usado em qualquer lugar em que um RealSubject esperado.RealSubject: Define o objeto real que o proxy representa.ProxyEstrutura

ProxyColaboraesDependendo do seu tipo, Proxy repassa solicitaes para RealSubject quando apropriado.ProxyAplicabilidade aplicvel sempre que h necessidade de uma referncia mais verstil ou sofisticada, do que um simples apontador para um objeto.ProxyExemplo PrticoApresentaremos um programa para um banco que faz uma conexo com o banco de dados para pegar algumas informaes relativas aos usurios do sistema.Deseja-se verificar se um usurio possui ou no permisso para visualizar as informaes do banco. Iremos utilizar uma classe para verificar se o usurio possui permisso de acesso e s ento exibir as informaes do banco. Vamos mostrar esta soluo utilizando o padro Proxy.

ProxyExemplo Prtico

ProxyExerccioDesenvolva um programa utilizando o padro Proxy, onde haja uma pasta em que se possa realizar operaes como ler, alterar e excluir arquivos.

Porm somente usurios autorizados podem realizar essas operaes.ProxyExerccio

ProxyConsequnciasIntroduz um nvelde referncia indireta no acesso a um objeto. A referncia indireta adicional tem muitos usos, dependendo do tipoUm proxy remoto pode ocultar o fato de que um objeto reside num espao de endereamento diferente.Um proxy virtual pode executar otimizaes, como a criao de um objeto sob demanda.Proxies de proteo permitem tarefas adicionais de organizao quando um objeto acessado.PadresComportamentaisPreocupam-se com algoritmos e a atribuio de responsabilidades entre objetos.No descrevem apenas padres de objetos ou classes, mas tambm os padres de comunicao entre eles.Caracterizam fluxos de controle difceis de seguir em tempo de execuo.Afastam o foco do fluxo de controle para permitir que se concentre somente na maneira como os objetos so interconectados.PadresComportamentaisOs padres comportamentais de classe utilizam a herana para distribuir o comportamento entre classes.

Os padres comportamentais de objetos utilizam a composio de objetos em vez da herana.Chain of ResponsabilityInteno:

Evitar o acoplamento do remetente de uma solicitao ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar a solicitao.

Encadear os objetos receptores, passando a solicitao ao longo da cadeia at que um objeto a trate.Chain of ResponsabilityAplicabilidadeUtiliza-se quando:Mais de um objeto pode tratar uma solicitao e o objeto que a tratar no for conhecido antes. O objeto que trata a solicitao deve ser escolhido automaticamente;Se deseja emitir uma solicitao para um dentre vrios objetos, sem especificar explicitamente o receptor.O conjunto de objetos que pode tratar uma solicitao deveria ser especificado dinamicamente.Chain of ResponsabilityParticipantesHandler:Define uma interface para tratar solicitaes.Implementa o link ao sucessor (opcional).ConcreteHandler:Trata de solicitaes pelas quais responsvel.Pode acessar seu sucessor.O ConcreteHandler trata a solicitao se puder, caso contrrio, a repassa para o sucessor.Cliente: Inicia a solicitao para um objeto ConcreteHandler da cadeia.Chain of ResponsabilityEstrutura

Chain of ResponsabilityColaboraesQuando um cliente emite uma solicitao, esta se propaga ao longo da cadeia at que um objeto ConcreteHandler assume a responsabilidade de trat-la.Chain of ResponsabilityExemplo PrticoVamos aplicar o padro Chain of Responsability em uma aplicao de e-commerce que precisa se comunicar com vrios bancos diferentes para fornecer aos seus usurios mais possibilidades de pagamentos, atingindo assim um nmero maior de usurios e facilitando suas vidas.Chain of ResponsabilityExemplo Prtico

Chain of ResponsabilityExerccioDesenvolva um programa de caixa eletrnico usando o padro Chain of Responsability que possua trs cofres, um para notas de 50, outro para notas de 20 e um para notas de 10.O programa deve solicitar a quantidade a sacar ao usurio, que deve ser mltipla de 10. Se o usurio digitar 0, o programa encerra.O programa deve ficar em um lao, sacando o valor em notas de 50, at isso no ser mais possvel, passando para as notas de 20 e em seguida de 10.Chain of ResponsabilityExerccioChain of ResponsabilityConsequnciasAcoplamento reduzido: Libera um objeto de saber qual objeto trata de uma solicitao. Um objeto s precisa saber que uma solicitao ser tratada apropriadamente. O receptor e o remetente no tm conhecimento um do outro, e um objeto que est na cadeia no necessita conhecer a estrutura da mesma.Pode simplificar as interconexes de objetos. Ao invs de manterem referncias para todos os receptores-candidatos eles mantm uma referncia nica para o seu sucessor.Chain of ResponsabilityConsequnciasFlexibilidade adicional na atribuio de responsabilidades a objetos: possvel acrescentar ou mudar responsabilidades para o tratamento de uma solicitao pelo acrscimo ou mudana da cadeia para o tratamento de uma solicitao pelo acrscimo ou mudana da cadeia em tempo de execuo. Pode-se combinar isto com subclasses para especializar estaticamente os manipuladores (handlers).Chain of ResponsabilityConsequnciasA recepo no garantida: Uma vez que uma solicitao no tem um receptor explcito, no h garantia de que ela ser tratada a solicitao pode sair pelo final da cadeia sem ter sido tratada.

Uma solicitao tambm pode no ser tratada quando a cadeia no est configurada apropriadamente.CommandInteno:

Encapsular uma solicitao, como um objeto, desta forma permitindo parametrizar clientes com diferentes solicitaes, enfileirar ou fazer o registro (log) de solicitaes e suportar operaes que podem ser desfeitas.CommandParticipantesCommand: Declara uma interface para a execuo de uma operao.ConcreteCommand: Define uma vinculao entre um objeto Receiver e uma ao;Implementa Execute atravs da invocao da(s) operao(es) correspondente(s) no Receiver.Client: Cria um objeto ConcreteCommand e estabelece o seu receptor.CommandParticipantesInvoker: Solicita ao Command a execuo da solicitao.

Receiver: Sabe como executar as operaes associadas a uma solicitao. Qualquer classe pode funcionar como um Receiver.CommandEstrutura

CommandColaboraesO cliente cria um objeto ConcreteCommand e especifica o seu receptor.Um objeto Invoker armazena o objeto ConcreteCommand.O Invoker emite uma solicitao chamando Execute no Command. Quando se deseja que os comandos possam ser desfeitos, ConcreteCommand armazena estados para desfazer o comando antes de invocar Execute.O objeto ConcreteCommand invoca operaes no seu Receiver para executar a solicitao.

AplicabilidadeUsa-se quando se deseja:

Parametrizar objetos por uma ao a ser executada. Especificar, enfileirar e executar solicitaes em tempos diferentes. Um objeto Command pode ter um tempo de vida independente da solicitao original. Se o receptor de uma solicitao pode ser representado de uma maneira independente do espao de endereamento, ento pode-se transferir um objeto command para um processo diferente e l atender a solicitao.

AplicabilidadeUsa-se quando se deseja:

Suportar desfazer operaes:

A operao Execute, de Command, pode armazenar estados para reverter seus efeitos no prprio comando. A interface de Command deve ter acrescentada uma operao Unexecute, que reverte os efeitos de uma chamada anterior de Execute.

CommandConsequncias

Desacopla o objeto que invoca a operao daquele que sabe como execut-la.Commands so objetos de primeira classe, ou seja, podem ser manipulados e estendidos como qualquer outro objeto.Pode-se montar comandos para formar um comando composto. fcil acrescentar novos Commands porque no preciso mudar as classes existentes.

CommandExemplo

Uma loja oferece vrias formas de pagamento.

Ao executar uma compra o sistema deve registrar o valor total e, dada uma forma de pagamento, por exemplo, carto de crdito, emitir o valor total da compra para o carto de crdito do cliente.

Iremos implementar este programa por meio do padro Command.

CommandExemplo

CommandExerccio

Implemente um programa que simule um sistema de arquivo com os mtodos abrir, gravar e fechar arquivos. O programa deve suportar mltiplos sistemas operacionais, como Windows e Unix.

CommandExerccio