Origem: Wikipédia, a enciclopédia livre. Show
Em Engenharia de Software, um padrão de desenho (português europeu) ou padrão de projeto (português brasileiro) (do inglês design pattern) é uma solução geral para um problema que ocorre com frequência dentro de um determinado contexto no projeto de software. Um padrão de projeto não é um projeto finalizado que pode ser diretamente transformado em código fonte ou de máquina, ele é uma descrição ou modelo (template) de como resolver um problema que pode ser usado em muitas situações diferentes. Padrões são melhores práticas formalizadas que o programador pode usar para resolver problemas comuns quando projetar uma aplicação ou sistema. Padrões de projeto orientados a objeto normalmente mostram relacionamentos e interações entre classes ou objetos, sem especificar as classes ou objetos da aplicação final que estão envolvidas. Padrões que implicam orientação a objetos ou estado mutável mais geral, não são tão aplicáveis em linguagens de programação funcional. Padrões de projeto residem no domínio de módulos e interconexões. Em um nível mais alto há padrões arquiteturais que são maiores em escopo, usualmente descrevendo um padrão global seguido por um sistema inteiro.[1] As características obrigatórias que devem ser atendidas por um padrão de projeto é composto basicamente por 4 (quatro) elementos que são:
Os padrões de projeto:
História[editar | editar código-fonte]O arquiteto Christopher Alexander,[2][3][4] em seus livros (1977/1979) Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, estabelece que um padrão deve ter, idealmente, as seguintes características:
Os patterns de Alexander procuravam prover uma fonte de ideias provadas para indivíduos e comunidades para serem usadas em construções, mostrando assim o quanto belo, confortável e flexível os ambientes podem ser construídos. 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. Em um trabalho para a conferência OOPSLA, eles apresentaram alguns padrões para a construção de aplicações comerciais em linguagem Smalltalk.[5] Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento destas ideias. Porém, o movimento ao redor de padrões de projeto só ganhou popularidade em 1995 quando foi publicado o livro Design Patterns: Elements of Reusable Object-Oriented Software. 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). Características de um padrão de projeto[editar | editar código-fonte]Embora um padrão seja a descrição de um problema, de uma solução genérica e sua justificativa, isso não significa que qualquer solução conhecida para um problema possa constituir um padrão, pois existem características obrigatórias que devem ser atendidas pelos padrões:[3] 1. Devem possuir um NOME, que descreva o problema, as soluções e conseqüências. Um nome permite definir o vocabulário a ser utilizado pelos projetistas e desenvolvedores em um nível mais alto de abstração. 2. Todo padrão deve relatar de maneira clara a qual (is) PROBLEMA(s) ele deve ser aplicado, ou seja, quais são os problemas que quando inserido em um determinado contexto o padrão conseguirá resolve-lo.Alguns podendo exigir pré-condições. 3. Solução descreve os elementos que compõem o projeto, seus relacionamentos, responsabilidades e colaborações. Um padrão deve ser uma SOLUÇÃO concreta, ele deve ser exprimido em forma de gabarito (algoritmo) que, no entanto pode ser aplicado de maneiras diferentes. 4. Todo padrão deve relatar quais são as suas CONSEQUÊNCIAS para que possa ser analisada a solução alternativa de projetos e para a compreensão dos benefícios da aplicação do projeto. Não pode ser considerado um padrão de projeto trecho de códigos específicos, mesmo que para o seu criador ele reflita um padrão, que soluciona um determinado problema, porque os padrões devem estar a um nível maior de abstração e não limitado a recursos de programação. Um padrão de projeto nomeia, abstrai e identifica os aspectos chaves de uma estrutura de projeto comum para torna-la útil para a criação de um projeto orientado a objetos reutilizável.[3] Padrões GoF ('Gang of Four')[editar | editar código-fonte]De acordo com o livro: "Padrões de Projeto: soluções reutilizáveis de software orientado a objetos", os padrões "GoF" são divididos em 24 tipos. Em função dessa grande quantidade de padrões, foi necessário classificá-los de acordo com as suas finalidades. São 3 as classificações/famílias:
Padrões "GoF" organizados nas suas 3 classificações/famílias: Padrões de criação[editar | editar código-fonte]
Padrões estruturais[editar | editar código-fonte]
Padrões comportamentais[3][editar | editar código-fonte]
Existem outros critérios de classificação dos padrões de projeto:
Outros Design Patterns[editar | editar código-fonte]Padrões arquiteturais[editar | editar código-fonte]
Padrões[6][7][8][editar | editar código-fonte]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 (General Responsibility Assignment Software Patterns), são responsáveis pela descrição de princípios de fundamental importância para a atribuição de responsabilidades em projetos orientados a objetos, oferecendo um melhor desempenho do código, e trabalhando acerca de solucionar problemas, garantindo melhor interface do projeto. Sendo assim, é importante sabermos que a qualidade do projeto orientado a objetos está diretamente relacionada com a distribuição dessas obrigações, que promovem a não sobrecarga de objetos já que ocorre nesse processo a delegação de atividades, ou seja, cada objeto terá uma função específica, de modo que, o que ele não souber fazer será repassado para o objeto que está mais preparado para fazer. Todos esses padrões servem para a resolução de problemas comuns e bastante típicos de desenvolvimento de software orientado a objeto. Portanto, tais técnicas apenas documentam e normatizam as práticas já consolidadas, testadas e conhecidas no mercado. 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. Tipos de Padrões Grasp[editar | editar código-fonte]Dentro do GRASP podemos encontrar vários padrões relacionados aqueles de caráter básicos e avançados.
Information Expert[editar | editar código-fonte]
Creator[editar | editar código-fonte]
High Cohesion[editar | editar código-fonte]
Low Coupling[editar | editar código-fonte]
Controller[editar | editar código-fonte]
Polymorphism[editar | editar código-fonte]
Pure Fabrication[editar | editar código-fonte]
Indirection[editar | editar código-fonte]
Protected Variations[editar | editar código-fonte]
Críticas[editar | editar código-fonte]Segundo alguns usuários, alguns "padrões de projeto" são apenas evidências de que alguns recursos estão ausentes em uma determinada linguagem de programação (Java ou C++ por exemplo). Nesta linha, Peter Norvig demonstra que 16 dos 23 padrões do livro 'Design Patterns' são simplificados ou eliminados nas linguagens Lisp ou Dylan, usando os recursos diretos destas linguagens.[9] Segundo outros, excessos nas tentativas de fazer o código se conformar aos 'Padrões de Projeto' aumentam desnecessariamente a sua complexidade.[10] Bibliografia[editar | editar código-fonte]
Referências
Ligações externas[editar | editar código-fonte]
São elementos do projeto de software?A seguir, temos a descrição dos princípios essenciais de um processo de software eficiente.. Visão: Desenvolver uma Visão. ... . Plano: Gerenciar para o Plano. ... . Riscos: Mitigar Riscos e Rastrear Problemas Relacionados. ... . Caso de Negócios: Examine o Caso de Negócios. ... . Arquitetura: Projete uma Arquitetura de Componente.. Quais são os 7 sete elementos de um projeto?Pensando em te nortear a desenvolver um termo de abertura do projeto, separei 7 elementos essenciais para sua elaboração, confira a seguir:. Business case. ... . Declaração do Problema. ... . Metas e objetivo específico. ... . Fatores Críticos de Sucesso. ... . Escopo do projeto. ... . Plano de trabalho. ... . Estrutura da equipe.. Quais são as etapas de um projeto de software?O processo de desenvolvimento de software é dividido em etapas: análise econômica, levantamento de requisitos, design do projeto, implementação, teste, documentação e suporte.
Quais são os 4 principais elementos de controle de um projeto?Entre essas ações estão:. Comparar o desempenho real com o planejado;. Analisar variações e tendências;. Avaliar alternativas possíveis;. Executar ações corretivas.. |