TrabalhosGratuitos.com - Trabalhos, Monografias, Artigos, Exames, Resumos de livros, Dissertações
Pesquisar

Java Padrao Grasp

Casos: Java Padrao Grasp. Pesquise 860.000+ trabalhos acadêmicos

Por:   •  3/10/2014  •  1.627 Palavras (7 Páginas)  •  660 Visualizações

Página 1 de 7

Padrão de projeto de software

Origem: Wikipédia, a enciclopédia livre.

Orientação a objetos

Objeto / Instância

Classe

Abstração

Atributo

Métodos

Mensagem

Encapsulamento

Herança / Herança múltipla

Associação

Polimorfismo

Interface

Outras referências

Paradigma de programação

Padrões de projeto

UML / RUP

Engenharia OO

v • e

Em engenharia de software, um padrão de projeto ou padrão de desenho (do inglês design pattern) é uma solução geral reutilizável 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

Um padrão de projeto define :

seu nome,

o problema,

quando aplicar esta solução e

suas consequências.

Os padrões de projeto :

visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do software - e

estabelecem um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.

Índice [esconder]

1 História

2 Padrões GoF

2.1 Padrões de criação

2.2 Padrões estruturais

2.3 Padrões comportamentais

3 Padrões GRASP

3.1 Padrões

4 Críticas

5 Bibliografia

6 Referências

7 Ligações externas

História[editar | editar código-fonte]

Christopher Alexander2 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:

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.

Além da definição das características de um padrão, Alexander definiu o formato que a descrição de um padrão deve ter. Ele estabeleceu que um padrão deve ser descrito em cinco partes:

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. Em um trabalho para a conferência OOPSLA, eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk.5 Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento destas idéias.

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

...

Baixar como (para membros premium)  txt (13.4 Kb)  
Continuar por mais 6 páginas »
Disponível apenas no TrabalhosGratuitos.com