Padrões de Projeto
•Transferir como PPTX, PDF•
0 gostou•514 visualizações
Padrões de Projeto
Recomendados
Mais conteúdo relacionado
Destaque
Semelhante a Padrões de Projeto
Mais de Sandy Maciel
Padrões de Projeto
- 3. Christopher Alexander -Notes on the Synthesis of Form, The Timeless Way of Building - A Pattern Language
- 4. Encapsulamento Generalidade Equilíbrio Abstração Abertura Combinatoriedade
- 5. Nome Exemplo Contexto Problema Solução
- 6. 1987 - Kent Beck e Ward Cunningham 1995 - Erich Gamma, Richard Helm, Ralph Jonshon e Jonh Vlissides Posteriormente, surgiram os outros padrões
- 8. Padrões de criação : relacionados à criação de objetos Padrões estruturais : tratam das associações entre classes e objetos. Padrões comportamentais : tratam das interações e divisões de responsabilidades entre as classes ou objetos.
- 9. Especialista na Informação Criador Controlador Acoplamento fraco Alta coesão Polimorfismo Indireção Variações Protegidas
- 16. Padrão de projeto para organização de testes funcionais
- 17. Esse padrão propõe criar um objeto para cada página web e utilizar a orientação objeto, onde guardaremos em cada classe os atributos e métodos (como campos e ações de cada página). O primeiro teste, geralmente, é o mais longo pois não temos nenhum objeto criado.
- 19. Objetos
- 20. Maior independência entre os teste; Maior aproveitamento de código; Quantos mais testes são criados, mais rápido fica a confecção de novos testes; Menor necessidade de refatorar ou debugar código, pois defeitos aparecerão na execução dos testes.
Notas do Editor
- Padrões são melhores práticas formalizadas que o programador pode usar para resolver problemas comuns quando projetar uma aplicação ou sistema
- Encapsulamento: um padrão encapsula um problema ou solução bem definida. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica. Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão. Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio. Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano. Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe. Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.
- Nome: uma descrição da solução, mais do que do problema ou do contexto. Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação. Contexto: a descrição das situações sob as quais o padrão se aplica. Problema: uma descrição das forças e restrições envolvidos e como elas interagem. Solução: relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.
- Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1995. Os autores desse livro, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, são conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF". Posteriormente, vários outros livros do estilo foram publicados, merecendo destaque Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto de padrões conhecidos como GRASP(General Responsibility Assignment Software Patterns).
- Os padrões "GoF" são organizados em 3 famílias : Padrões de criação : relacionados à criação de objetos Padrões estruturais : tratam das associações entre classes e objetos. Padrões comportamentais : tratam das interações e divisões de responsabilidades entre as classes ou objetos.
- Os padrões GRASP, sigla para General Responsibility Assignment Software Patterns (or Principles), consistem de um conjunto de práticas para atribuição de responsabilidades a classes e objetos em projetos orientados a objeto. Os padrões GRASP estão mais como uma ferramenta mental ou uma filosofia de design, mas que ainda assim são úteis para o aprendizado e desenvolvimento de um bom design de software. Note que alguns padrões GoF implementam soluções correspondentes com padrões GRASP. A principal obra sobre o assunto foi o livro "Utilizando UML e Padrões"
- Padrões são melhores práticas formalizadas que o programador pode usar para resolver problemas comuns quando projetar uma aplicação ou sistema
- O mais importante sobre os padrões é que eles são soluções aprovadas. Cada catálogo inclui apenas padrões que foram considerados úteis por diversos desenvolvedores em vários projetos. Os padrões catalogados também são bem definidos; os autores descrevem cada padrão com muito cuidado e em seu próprio contexto, portanto será fácil aplicar o padrão em suas próprias circunstâncias. Eles também formam um vocabulário comum entre os desenvolvedores. Leia mais em: Conheça os Padrões de Projeto http://www.devmedia.com.br/conheca-os-padroes-de-projeto/957#ixzz3ERRKz83N
- Os padrões são um mapa, não uma estratégica. O conceito de utilizar os padrões de forma indiscriminada é conhecida como antipadrões Existem duas noções de antipadrões: Aqueles que descrevem uma solução ruim para um problema que resultou em uma situação ruim; Aqueles que descrevem como se livrar de uma situação ruim e como proceder dessa situação para uma situação boa. Em suma um antipadrão constitui ao uso indevido dos padrões de projeto, ou o seu uso exagerado, o que pode ser constatado pela utilização de padrões impróprios para um determinado contexto, ou uso inadequadoo/957#ixzz3ERRt2ZVT
- O alvo principal do uso dos padrões de projeto no desenvolvimento de software é o da orientação a objetos. Como os objetos são os elementos chaves em projetos OO, a parte mais difícil do projeto é a decomposição de um sistema em objetos. A tarefa é difícil porque muitos fatores entram em jogo: encapsulamento, granularidade, dependência, flexibilidade, desempenho, evolução, reutilização e assim por diante. Todos influenciam a decomposição, freqüentemente de formas conflitantes Leia mais em: Conheça os Padrões de Projeto http://www.devmedia.com.br/conheca-os-padroes-de-projeto/957#ixzz3ERSN99U6
- Considerar como os padrões de projeto solucionam problemas de projeto. Examinar qual a intenção do padrão, ou seja, o que faz de fato o padrão de projeto, quais seus princípios e que tópico ou problema particular de projeto ele trata (soluciona). Estudar como os padrões se relacionam. Estudar as semelhanças existentes entre os padrões. Examinar uma causa de reformulação de projeto. Considerar o que deveria ser variável no seu projeto, ou seja, ao invés de considerar o que pode forçar uma mudança em um projeto, considerar o que você quer ser capaz de mudar sem reprojetá-lo.
- Ler o padrão por completo uma vez, para obter sua visão geral. Conhecer o padrão principalmente a sua aplicabilidade e conseqüências são importantes para que ele realmente solucione o seu problema; Estudar seções Estrutura, Participantes e Colaborações. Assegurando-se de que compreendeu as classes e objetos no padrão e como se relacionam entre si; Escolher os nomes para os participantes do padrão que tenham sentido no contexto da aplicação; Definir as classes. Declarar as interfaces, estabelecer os seus relacionamentos de herança e definir as variáveis de instância que representam dados e referências a objetos. Identifique as classes existentes na aplicação que serão afetadas pelo padrão e modifique-as; Defina os nomes específicos da aplicação para as operações no padrão. Os nomes em geral dependem da aplicação. Use as responsabilidades e colaborações associadas com cada operação como guia; Implemente as operações para suportar as responsabilidades e colaborações presentes do padrão. A seção de Implementação oferece sugestões para guiá-lo na implementação.
- hefhsfhshfsfhskjdfhskjfh
- hefhsfhshfsfhskjdfhskjfh
- hefhsfhshfsfhskjdfhskjfh
- hefhsfhshfsfhskjdfhskjfh
- hefhsfhshfsfhskjdfhskjfh
- hefhsfhshfsfhskjdfhskjfh
- hefhsfhshfsfhskjdfhskjfh