PADROES_PROJETO_INTRODUCAO

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
*
PADRÕES DE PROJETO
INTRODUÇÃO
*
*
PADRÕES DE PROJETO
Introdução
Padrões de Software são soluções reutilizáveis para problemas reincidentes que ocorrem durante o desenvolvimento de softwares.
São descrições de classe e objetos comunicantes que precisam ser personalizadas para resolver um problema geral de projeto num contexto particular *obs: página 20 material
*
*
PADRÕES DE PROJETO
Um analista já acostumado com os padrões consegue, com grande facilidade, reconhecer soluções para problemas recorrentes e também onde e quando aplicar o padrão necessário para o problema encontrado.
*
*
PADRÕES DE PROJETO
A UML (Unified Modeling Language) define responsabilidade como um contrato ou obrigação de um classificado.  As responsabilidades estão relacionadas com as obrigações de um objeto em termos de comportamento.  As responsabilidades podem ser de dois tipos: 
CONHECER   -    Ter conhecimentos sobre dados privados
                           encapsulados;
                          - Conhecer objetos relacionados;
                          - Ter conhecimento sobre coisas que ele 
                          pode derivar ou calcular;
FAZER           -    Criar um objeto ou executar um cálculo;
                          - Iniciar uma ação em outro objeto;
                          - Controlar e coordenar atividades em  
                          outros objetos;
 
COMO DESCREVER **ler capítulo 1 do livro item 1.3 ou página 22 do livro
*
*
PADRÕES DE PROJETO
Descrever um padrão é representá-lo em linhas gerais e, existe uma regra básica para a descrição de um padrão. Basicamente cada padrão descrito deverá conter as seguintes informações: Nome, Problema, Sumário, Solução, Conseqüências e Padrões Relacionados:
*
*
PADRÕES DE PROJETO
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.
Sumário: Descrever os passos até a chegada de uma solução geral do problema.
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 geral de 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 DE PROJETO
Padrões de Criação (Creational Patterns): Fornecem um guia de como criar objetos, na medida em que, suas criações requerem tomadas de decisão. Essas decisões normalmente serão dinâmicas e envolverão qual classe instanciar ou quais objetos irão delegar responsabilidade. Esse padrão nos diz como estruturar e encapsular essas decisões.
Padrões de Divisão (Partitioning Patterns): Uma estratégia conhecida para resolução de problemas é chamada de dividir para conquistar. O escopo desses tipos de padrões é dividir um problema complexo em pequenas partes, fazendo com que esse problema fique com várias pequenas partes de fácil resolução. Os padrões englobados nesse escopo irão ensinar como dividir classes e interfaces no sentido de torná-las fáceis proporcionando, um bom design.
Padrões Estruturais (Structural Patterns): Definem caminhos comuns para a organização de diferentes tipos de objetos, no sentido de trabalharem em uns com os outros.
Padrões Comportamentais (Behavioral Patterns): Organizam, gerenciam e combinam comportamentos.
Padrões de Concorrência (Concurrency Patterns): Dizem respeito a controle de operações concorrentes. 
*
*
PADRÕES DE PROJETO
Padrões GRASP (GRASP Patterns): General Responsibility Assignment Software Patterns. Mostra o design dos princípios da orientação a objetos na forma de padrões. Provêem direções para a atribuição de responsabilidades para classes e ainda podem, em alguns casos, dizer quais classes serão desenhadas.
Padrões para design de interface com o usuário (GUI Design Patterns): Estabelecem padrões para a criação e desenho de interfaces com o usuário.
Padrões para a organização de códigos (Organizational Coding Patterns): Ditam como organizar o código no sentido de torná-los fáceis de ler e manter.
Padrões para otimização de códigos (Coding Optimization Pattern): Descrevem regras para a otimização de códigos a fim de melhorar a performance de um programa.
Padrões de Robustez de Códigos (Code Robustness Patterns): Estabelecem padrões para tornar o código mais robusto.
Padrões de Testes (Tests Patterns): Descrevem vários métodos para testar softwares.
*
*
PADRÕES GOF
Os Padrões GoF (Group of Four): Conhecido como padrões da gangue dos quatro, por terem sido desenvolvidos por quatro autores, Os Padrões GoF (Group of Four) estão divididos pelos seguintes famílias de padrões: Padrões de Criação ou de Construção, Padrões Estruturais e Padrões Comportamentais.Os padrões de Criação ou de Construção são relacionados à criação de objetos, os Padrões Estruturais tratam das associações entre classes e objetos e os Padrões Comportamentais das interações e divisões de responsabilidades entre as classes ou objetos.
Um padrão "GoF" também é classificado segundo o seu escopo: de classe ou de objeto
*
*
PADRÕES GOF
·     Padrões de Criação ou de Construção: Abstract Factory, Builder, Factory Method, Prototype e Singleton.
·     Padrões Estruturais: Adapter, Bridge, Composite, Decorator, Facade, Flyweight e Proxy.
· 	 Padrões Comportamentais: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.
	Os padrões mais utilizados são os padrões GRASP e GoF.
*
*
ARQUITETURA EM CAMADAS
O desenvolvimento de software se dá em duas partes: parte lógica e parte física. 
A parte lógica:
 consiste no entendimento e modelagem dos requisitos de sistemas.
 A parte física:
 projeta o sistema definindo a estrutura (hw/sw) necessária para suportar as necessidades definidas. A essa estrutura denominamos de arquitetura. 
 
  
A arquitetura é definida de acordo com o ambiente operacional disponível, como: linguagens de programação, sistemas operacionais e equipamentos. Por esse motivo, na medida em que a evolução da engenharia de software acontece o tipo de arquitetura varia. Assim, até hoje desenvolvemos softwares em arquitetura centralizada, cliente-servidor e camadas, utilizada atualmente na construção de softwares orientados a objetos. Cada uma com sua característica define a melhor estrutura para implantação de softwares.
*
*
ARQUITETURA EM CAMADAS
A arquitetura centralizada :
supõe a execução dos sistemas centralizada em uma única máquina com compartilhamento dos recursos.
 
A arquitetura cliente-servidor, também chamada de duas camadas:
distribui o processamento em duas partes: uma para o servidor, onde concentra as funções de controle e domínio e, outra parte no cliente com a execução das interfaces. Assim o fluxo de utilização e compartilhamento de recursos diminui, o que gera um melhor rendimento nas operações.
A arquitetura em três camadas:
 propõe o desenvolvimento de softwares baseado em três partes: interface, controle e domínio.
*
*
ARQUITETURA EM CAMADAS
A arquitetura em camadas permite visualizar o sistema de software como um conjunto de camadas.  Uma camada de software é uma coleção de unidades de software (programas ou módulos) que podem ser executadas ou acessadas.
O princípio básico que deve ser seguido
é que as camadas mais altas devem depender das camadas mais baixas.
 
O padrão Camada está relacionado com a arquitetura lógica, ou seja, descreve a organização conceitual dos elementos de projeto em grupos, independentemente de seu empacotamento ou de sua implantação física.
*
*
ARQUITETURA EM CAMADAS
CAMADA DE APRESENTAÇÃO
É composta de classes que constituem a funcionalidade para visualização dos dados pelos usuários e interface com outros sistemas.
As classes de fronteira se encontram nessa camada. 
Exemplos de camadas de apresentação: um sistema de menus baseados em texto; uma página escrita em HTML ou XHTML com JavaScript apresentada em um navegador de Internet; uma interface gráfica construída em algum ambiente de programação.
·        CAMADA DE LÓGICA DA APLICAÇÃO
É composta de classes que implementam as regras do negócio no qual o sistema está para ser implantado.
Nessa camada, são realizadas computações com base nos dados armazenados ou nos dados de entrada.  Também são feitas validações de dados provenientes da camada de apresentação.  As classes de controle e as classes de entidade se encontram nessa camada.
·     CAMADA DE ACESSO
Contém classes que se comunicam com outros sistemas para realizar tarefas ou adquirir Informações. Esta camada é implementada utilizando a tecnologia de banco de dados, em que um SGBD executa em um ou mais nós de processamento de alto desempenho. 
*
*
MVC
A abordagem MVC (Modelo/Visão/Controlador) define a lógica da implementação em camadas. É composta por três tipos de objetos: Modelo, Visão e Controlador. O Modelo é o objeto da aplicação, a Visão é a apresentação na tela e o Controlador é o que define a maneira como a interface reage às entradas do usuário. A abordagem separa a Visão e os Modelos pelo estabelecimento de um protocolo do tipo inserção / notificação, aumentando a flexibilidade e reutilização.
VANTAGENS
Permite acoplamento baixo entre as camadas, maior grau de manutenção e reutilização de objetos;
Facilidade em novas implementações (ex. incluir uma camada de apresentação para utilização de ambiente web);
Mais adaptáveis a uma quantidade maior de usuários. pode-se dividir a carga de processamento do sistema entre as camadas de lógica da aplicação e acesso;
DESVANTAGENS
Diminuir potencialmente o desempenho: a cada camada, as representações dos objetos sofrem modificações, e essas modificações levam tempo para serem realizadas;
 
*
*
PADRÕES DE CRIAÇÃO
Os padrões de criação abstraem o processo de instanciação. Ajudam a tornar um sistema independente de como seus objetos são criados, compostos e representados. Um padrão de criação de classe usa herança para variar a classe que é instanciada enquanto que um padrão de criação de objeto delegará a instanciação para outro objeto.
A tendência é definir um conjunto menor de comportamentos fundamentais. Os padrões de criação oferecem muita flexibilidade ao que, como e quando é criado e a quem cria.
*
*
PADRÕES DE CRIAÇÃO
ABSTRACT FACTORY
Fornece uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes completas.
Deve ser usado quando:
Um sistema deve ser independente de como seus produtos são criados, compostos ou representados;
um sistema deve ser configurado como um produto de uma família de múltiplos produtos;
Uma família de objetos-produto for projetada para ser usada em conjunto e você necessita garantir essa restrição;
Você quer fornecer uma biblioteca de classes de produtos e quer revelar somente suas interfaces, não suas implementações.
Apresenta as seguintes conseqüências:
 Isola as classes concretas;
 Torna fácil a troca de famílias de produtos;
 Promove a harmonia entre produtos; 
 É difícil de suportar novos tipos de produtos
*
*
PADRÕES DE CRIAÇÃO
BUILDER
Separa a construção de um objeto complexo da sua representação de modo que o mesmo processo de construção possa criar diferentes representações.
Deve ser usado quando:
O algoritmo para criação de um objeto complexo deve ser independente das partes que compõe o objeto e de como elas são montadas;
O processo de construção deve permitir diferentes representações para o objeto que é construído;
Apresenta as seguintes 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 fino sobre o processo de construção;
*
*
PADRÕES DE CRIAÇÃO
FACTORY METHOD
Define uma interface para criar um objeto, mas deixa as subclasses decidirem que classe instanciar. O padrão permite adiar a instanciação para subclasses.
Deve ser usado quando:
Uma classe não pode antecipar a classe de objetos que deve criar;
Uma classe quer que suas subclasses especifiquem os objetos que criam;
Classes delegam responsabilidade para uma dentre várias subclasses auxiliares, e o sistema precisa localizar o conhecimento de qual subclasse auxiliar que é a delegada;
Apresenta as seguintes consequencias:
Fornece flexibilidade para criação de objetos;
Conecta hierarquias de classes paralelas;
*
*
PADRÕES DE CRIAÇÃO
SINGLETON
Especifica os tipos de objetos a serem criados usando uma instância-protótipo e cria novos objetos a partir do mesmo
Quando você necessita de somente uma instância da classe, por exemplo, a conexão com banco de dados, vamos supor que você terá que chamar diversas vezes a conexão com o banco de dados em um código na mesma execução, se você instanciar toda vez a classe de banco, haverá grande perda de desempenho, assim usando o padrão singleton, é garantida que nesta execução será instânciada a classe somente uma vez. Lembrando que este pattern é considerado por muitos desenvolvedores um anti-pattern, então, cuidado onde for utilizá-lo.
Consequencias:
Permite o controle sobre como e quando os clientes acessam a instância.
Várias classes singleton podem obedecer uma mesma interface, permitindo assim que um singleton em particular seja escolhido para trabalhar com uma determinada aplicação em tempo de execução.
Com apenas uma implementação interna do singleton pode-se fazer com que o singleton crie um número controlado de instâncias.
É mais flexível que métodos estáticos por permitir o polimorfismo.
*
*
PADRÕES DE CRIAÇÃO
PROTOTYPE
O padrão Prototype pode ser utilizado em sistemas que precisam ser independentes da forma como os seus componentes são criados, compostos e representados. O padrão Prototype pode ser útil em sistemas com as seguintes características:
sistemas que utilizam classes definidas em tempo de execução;
sistemas que utilizam o padrão Abstract Factory para criação de objetos. Neste caso, a hierarquia de classes pode se tornar muito complexa e o padrão Prototype pode ser uma alternativa mais simples, por realizar a mesma tarefa com um número reduzido de classes;
sistemas que possuem componentes cujo estado inicial possui poucas variações e onde é conveniente disponibilizar um conjunto pré-estabelecido de protótipos que dão origem aos objetos que compõem o sistema.
Quando utiliza o framework Spring, por exemplo, um desenvolvedor pode configurar um JavaBean como "prototype". Esta configuração faz com que cada uma das referências a um JavaBean aponte para uma instância diferente. O comportamento padrão, ou singleton, define que todas as referências a um JavaBean apontem para a mesma instância de uma classe.
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*