Extreme Programming, Variações Protegidas e Padrão não Fale com Estranhos - Aula 32

Nas ultimas aulas do semestre, conhecemos o ultimo Padrão Grasp que é Variações Protegidas, e Padrão Não fale com estranhos, pra encerrar foi comentado a respeito sobre Extreme Programming ou XP que é um Processo de desenvolvimento de Software voltado para projetos cujos requisitos são vagos e mudam com freqüência.


Extreme Programming

A muito tempo a indústria de software vem passando por grandes transformações e novos desafios, entre eles desenvolver softwares com qualidade, no menor tempo possível e que atendam as necessidades dos clientes.
Com estes novos desafios a indústria de software passou a dar valor a algumas áreas da informática, como a engenharia de software e qualidade de software, com intuito de atender as exigências do mercado.
A indústria começou a utilizar metodologias de desenvolvimento de software, adotou métricas e padrões para alcançar níveis aceitáveis de qualidade, prever custos e prazos em seus projetos. Porém ainda são poucos os projetos que conseguem obter pleno sucesso em seu desenvolvimento, onde prazo e orçamento estabelecidos e as necessidades do cliente sejam realmente atendidas.
Pesquisa feitas pelo Standish Group International em 1994, um pouco antes da adoção de metodologia de desenvolvimento pelas indústrias, apontam que apenas 16, 2 % dos projetos de software atingiam sucesso (prazo, orçamento e funcionalidades atendidas). Em 2002 esta taxa havia subido para 34 %, ou seja, um aumento de 100 % em 8 anos. Mas estas taxas ainda se encontram muito aquém do esperado pelo mercado.
As metodologias utilizadas nos projetos pesquisados eram as mais variadas, podemos citar modelo em cascata, modelo iterativo e alguns com modelo em prototipação. Neste trabalho será utilizado o termo desenvolvimento tradicional para os projetos que se utilizem do modelo em cascata e todos os outros que se baseiam nele.
Analisando os motivos para a baixa taxa de sucesso dos projetos desenvolvidos com modelos tradicionais, cita-se os principais motivos e bastante comuns entre eles:
Tempo elevado entre cada fase do projeto, não acompanhando as mudanças de requisitos do projeto;
Falta de conhecimento por parte do cliente da sua real necessidade, dando margem às especulações dos desenvolvedores;
Forte linearidade no desenvolvimento do projeto;
Focando nas fragilidades do modelo tradicional, surgiram metodologias para desenvolvimento ágil de software. Cita-se algumas características destas metodologias:
Foco nas pessoas, não no processo, evitando especulações dos desenvolvedores;
Atender as reais necessidades do cliente, na velocidade e praticidade por ele desejada;
Ausência de linearidade no desenvolvimento do projeto;
O cliente aprender a suas reais necessidades durante o projeto e repassar esta novas necessidades a equipe de desenvolvimento;

Uma destas metodologias de desenvolvimento ágil é o Extreme Programming , metodologia que prima a qualidade do software desenvolvido, que atenda as reais necessidades do cliente e seja entregue dentro do prazo definido. Esta metodologia será detalhada a seguir.
Extreme Programming (XP)
XP é uma metodologia para desenvolvimento de software ágil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prática e a perseguição da mais clara simplicidade, aplicado ao desenvolvimento de software.
Uma metodologia voltada para projetos cujos requisitos mudem com freqüência, utilizem desenvolvimento orientado a objetos, equipes de até 12 desenvolvedores e desenvolvimento incremental.
A XP Busca o máximo de valor a cada dia de trabalho da equipe para o seu cliente. Em um curto espaço de tempo o cliente terá um produto que possa ser utilizado, podendo aprender com o mesmo e reavaliar se o que foi desenvolvido é realmente o desejado.
Por ser uma metodologia recente, a XP sofre mudanças em suas concepções e, portanto, é comum encontrar variações. A adaptação ao ambiente de desenvolvimento deve ser levada em conta, se um valor trouxer mais prejuízos do que benefícios é necessário relavaliar a utilização desta metodologia.
A XP é organizada em torno de um conjunto de práticas e valores que atuam perfeitamente para assegurar um alto retorno do investimento efetuado pelo cliente. A seguir serão apresentados os valores e em seguida as práticas.




Variações Protegidas

Como atribuir responsabilidades a objetos, subsistemas e sistemas, de modo que as variações ou a instabilidade nesses elementos não tenham um impacto indesejável sobre outros elementos?Identifique pontos de variação ou instabilidade prevista; atribua responsabilidades para criar uma interface estável em torno deles
Toda aplicação tem pontos de variação, identifique os pontos de variação ou instabilidade prevista, atribuindo responsabilidades para criar uma interface estável em torno deles. Na variação protegida temos as variações evolutivas e as variações corretivas.

Mecanismos de Variações Protegidas· Agentes (Brokers) – é encarregado de levar as requisições que recebe, localiza qual local de destino e entrega ao local correto.· Máquinas Virtuais – simulam vários sistemas em um único meio físico, dá maior portabilidade aos sistemas em ambientes instáveis.· Projetos dirigidos por dados (dataDriver design) – troca de informações entre aplicações através de arquivos configurados por exemplo XML, framework Spring, TomCat, etc.· Pesquisa de serviços – é ter alguém que forneça serviços, e ter alguém que consome os serviços disponibilizados, podemos citar como exemplo o novo paradigma SOA.· Projetos dirigidos por interpretadores – são aplicações que interpretam ambientes ou sistemas diferentes, por exemplo JVM, Engine Regras.


Padrão não Fale com Estranhos

-Motivação: O objetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados.

-Objetos referenciados diretamente – “familiares”-Objetos referenciados indiretamente – “estranhos”

-Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.
-Problema: Como evitar o conhecimento da estrutura de objetos indiretamente referenciados?-Solução: Atribuir responsabilidade a um objeto diretamente referenciado por um cliente, de forma que este colabore mantendo contato com o objeto “estranho” (indiretamente referenciado)
-Lei de Demétrio-Dentro de um método, as mensagens devem ser enviadas somente para os seguintes objetos:-O objeto this (ou self)-Um parâmetro do método-Um atributo de self-Um elemento de uma coleção que é um atributo de self-Um objeto criado dentro do método.

http://www.javafree.org/content/view.jf?idContent=5 Acessado em 12 Jun 2008, 14:21;

Microsoft Corporation Groups, GRASP - Padrões de Software para Atribuição de Responsabilidade Gerais, Disponível em:<http://groups.msn.com/cafedotnet/grasppadresdesoftware.msnw> Acessado em 12 Jun 2008, 13:21;

Padrão Pura Invensão e Indireção - Aula 31

O post passado a respeito de polimorfismo, que tem como problema tratar alternativas baseadas no tipo, criar componente de software “plugáveis”. E foi resolvido atribuindo responsabilidades aos tipos usando operações polimóficas.
Agora vamos dar continuidade aos Padrões Grasp Pura Invenção e Indireção.


Pura Invenção

Problema:

Que objeto deve ter a responsabilidade quando você não quer violar “ Alta Coesão” e “ Baixo Acoplamento”, mas as soluções oferecidas pelo “Especialista” não são apropriadas?

Solução:

Atribua um conjunto coeso de responsabilidade a uma classe artificial que não representa um conceito no domínio da aplicação, uma classe fictícia que possibilite alta coesão, baixo acoplamento e o reuso.





O especialista nos diz para atribuir a responsabilidade à classe Venda, uma vez que ela conhece os dados de venda. Considere no entanto as seguintes implicações:
Salvar um objeto no Banco de Dados implica em uma série de operações não relacionadas ao conceito de venda.
A classe venda tem de ser associada à interface do banco de dados relacional (JDBC, por exemplo)
Várias outras classes no projeto terão de fazer a mesma coisa.

Beneficios:
-É considerada como parte da camada de serviços de alto nível OO em uma arquitetura.-Invenção pura são objetos tipicamente centrados na funcionalidade (cuidado com abusos para não perder o espírito de bons projetos OO!).
-Cria-se objetos mais genéricos e reutilizáveis: a própria classe inventada. É importante ter isso em mente
-Melhora acoplamento e coesão: a classe venda permanece bem projetada.

Indireção

Problema:

Onde colocar uma responsabilidade de modo a evitar o acoplamento direto entre duas ou mais classes? Como desacoplar objetos de modo a possibilitar o baixo acoplamento e manter alta a possibilidade de reuso?

Solução:

Atribua a responsabilidade a um objeto intermediário que faça a mediação entre componentes ou serviços de modo que ele não sejam diretamente acoplados.

A fundamental finalidade de se usar O Padrão Indireção, é que pode-se atribuir a encargo a um objeto intermediário que faz mediação entre os outros componentes ou serviços de modo que eles não estejam diretamente acoplados. O objeto intermediário cria uma camada de indireção entre os dois componentes que não dependem um do outro: agora ambos dependem da indireção.

Benefício: Acoplamento fraco – com o objetivo de desacoplar outros componentes ou serviços, introduz-se uma indireção.
Muitas invenções puras são conseqüências da indireção.

“A maior parte dos problemas em Ciência da Computação pode ser resolvida por um nível adicional de indireção” .

Velho provérbio com especial relevância para sistemas orientados a objeto.

http://equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt#815,62,Indireção Acessado em 08 Junho 2008, 22:23

Wikimedia Foundation, Inc, Spring Framework, Disponível em: <http://en.wikipedia.org/wiki/Spring_framework> Acessado em 08 Junho 2008, 22:16;GRASP Patterns, Disponível em:<http://equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt> Acessado em 08 Junho 2008, 22:59;ROCHA, Helder, Padrões de Design com aplicações em JAVA, Disponível em:<http://www.argonavis.com.br/cursos/java/j930/tutorial/Design_Patterns.pdf> Acessado em 08 Junho 2008, 22:33;

Padrão Polimorfismo - Aulas 29-30

Bom, nesta postagem iremos tratar a respeito de Padrões GRASP: Padrões Gerais de Atribuição de Responsabilidades de Software, conforme já vimos neste blog, já falamos a respeito de padrões Especialista, Criador, Coesão Alta, Acoplamento Fraco e Controlador. E nos próximos posts iremos continuar a tratar sobre o princípios fundamentais de atribuição de responsabilidades, que envolve
Polimorfismo
Invenção Pura (Pure Fabrication)
Indireção (Indirection)
Não fale com estranhos (Don’t talk to strangers)


Polimorfismo


Alternativas com base no tipo: variação condicional é comumente encontrada em programas.
Uso de lógica condicional: torna difícil a extensão de um programa para atender novas variantes, pois mudanças são necessárias em vários lugares.
Componentes de software “conectáveis” : sendo os componentes do tipo cliente-servidor, como substituir um componente servidor, sem afetar o cliente?


Problema: Como tratar alternativas com base no tipo ? Como criar componentes de software conectáveis ?
Solução: Atribuir responsabilidade pelo comportamento, aos tipos para os quais o comportamento varia, usando operações polimórficas.
Corolário: não teste o tipo de um objeto nem use condições lógicas no código para executar alternativas que variam com base no tipo


Exemplo: No sistema TPV, quem deveria ser o responsável pela autorização de diferentes tipos de pagamentos?
Como a autorização varia de acordo com o tipo de pagamento (dinheiro, cartão de crédito ou cheque), usando o padrão Polimorfismo devemos atribuir a responsabilidade à cada tipo de pagamento, implementada como uma operação polimórfica autorizar.


Polimorfismo (Benefícios)


Facilidade de extensão: futuras extensões, quando necessárias para novos tipos não previstos, são fáceis de acrescentar
Objetos clientes: necessitarão pouca ou nenhuma modificação, na medida que o novo servidor suporte as operações polimórficas esperadas pelo cliente

Exercícios - Aulas 27 e 28

Agora iremos postar alguns exercicios comentado durante as aulas.

Exercícios:

1º) Um objeto "A" precisa executar um método quando o estado do objeto "B" for alterada. Qual o padrão GOF deve ser usado? Qual o papel do objeto "B" e do objeto "A" nesse padrão?
Resposta

Padrão observer,
você deve pensar que um objeto, que chamarei de "A", irá executar uma ação que outros deverão capturar, que chamarei de "B".


2º) Qual o padrão GOF deve ser usado quando necessitamos executar diversas ações de forma atômica?
Resposta
Padrão Command.
Permite Encapsular uma solicitação como um objeto, permitindo desta forma parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas



3º) Uma classe de conexão só pode ter, no máximo, 10 instâncias. Qual o padrão GOF a usar?Resposta

Padrão Singleton



4º) Duas classes "A" e "B" tem iterfaces distintas. Qual o padrão deve ser usado se a classe "B" precisar um método da classe "A" ?
Resposta

Padrão Adapter, pois tem função que faz com que a interface de uma classe possa ser "adaptada" à interface de uma outra para que essas possam trabalhar juntas.



5º) Voçê deseja que uma classe de terceiros use um método de sua classe. Qual o melhor padrão?

Padrão Command.
Esta operação pode ser encapsulada em um objeto, assim reduziremos o acoplamento entre o as camadas.

Padrão MVC - Aula 25 e 26

Introdução.

Agora em diante iremos abordar ao assunto de PADRÕES DA CAMADA DE APRESENTAÇÃO
Serão apresentados neste capítulo padrões para a camada de apresentação. A camada de Apresentação é a parte do sistema onde ficam os objetos responsáveis por fornecer algum serviço a uma entidade externa, seja essa entidade uma pessoa e a resposta em páginas.

Padrão MVC

Model View Controler (MVC)

O MVC é um padrão que serve para organizar as iterações entre os componentes da camada de apresentação. Esse padrão define três tipos de componentes:
• View são componentes que geram a parte da aplicação visível ao usuário do sistema. Pode ser uma pagina JSP, uma Janela Swing, um arquivo XML, entre outros. A View deve implementar o padrão Observer (FREEMAN et al, [199?]) em cima dos objetos do Model. Sempre que um objeto do Model mudar isso deve ser refletido nas Views que possam estar associadas ao referido objeto e conseqüentemente, nos dados que são mostrados ao usuário.
• Model são os componentes que contém as informações que vão ser mostradas na View. Pode ser o próprio objeto do modelo da aplicação (objeto da Camada de Modelo, Capítulo 4) ou apenas uma interface para os objetos do modelo.
• Controler são os componentes responsáveis por capturar solicitações vindas da View e as despacha para o Model. Além de atualizar a View apropriadamente. Para sistemas simples, onde a camada de aplicação não possui muitas funcionalidades, o Controler acaba as implementando.
É bom ressaltar, os três tipos de componentes acima pertencem a Camada de Apresentação e não são camadas separadas do sistema. Mas para aplicações simples, é aceitável Controler seja utilizando como substituto da Camada de Aplicação e Model como substituto da Camada de Modelo1.

O MVC com todas as suas funcionalidades não é possível de ser implementado em aplicações Web, visto que o protocolo HTTP não permite que o servidor, onde está o modelo, notifique o cliente onde está a View. O que realmente é implementado em aplicações Web é o padrão Front Controller (FOWLER,et al, 2002).
Normalmente não é preciso implementar esse padrão quando vai se desenvolver um sistema. Muitos Frameworks que trabalham com a Camada de Apresentação já o implementam, basta apenas utilizá-lo, como é o caso dos componentes Swing para aplicações desktop em Java.

Existem duas discussões sobre o padrão MVC: separar o Controler da View e separar a View do Model (FOWLER,et al, 2002). A primeira é menos importante e deve ser feita apenas quando a situação realmente exigir. A separação da View do Model é umas das mais importantes indicações de bom design de software. Entre as inúmeras vantagens pode-se citar:

• Desenvolvedores se especializam em apenas em das áreas, ou no design e técnicas de usabilidade de software ou construção de lógica de negócio, acesso a Banco de Dados, desempenho, entre outros. É difícil encontra um desenvolvedor que seja bom nas duas áreas (FOWLER,et al, 2002).
• Geralmente, softwares devem mostrar a mesma informação de maneiras diferente, dependendo do contexto que se tenha, locais e meios de acesso distintos, usuários com diferentes permissões, separar View do Model permite desenvolver múltiplas apresentações para o mesmo conteúdo.
• Objetos não visuais são mais fáceis de serem testados.

O ponto chave para essa separação é que a View pode depender do Model, mas o Model deve ser independente da View. O esquema de dependência do padrão MVC é mostrado na Figura abaixo:

Esquema de dependências do padrão MVC

Padrão COMMAND - Aula 23 e 24

Padrão COMMAND

A principal função do padrão Command é encapsular invocações a objetos. Quando invocar objetos torna-se uma tarefa complexa, como é o caso de invocar componentes remotos na especificação EJB 2.1, há a necessidade de se encapsular essas invocações para se simplificar o código. Com isso são abstraídas, para o cliente, coisas do tipo: onde, quando ou qual componente vai realizar uma determinada tarefa.
O principio do padrão é guardar um “objeto comando” para cada objeto a ser invocado. Para invocar o objeto destino, invoca-se sempre o mesmo método do “objeto comando” (geralmente chamado de execute) e esse método padrão de um comando se encarrega de chamar os métodos adequados para realizar as ações requeridas. Com isso evita-se que o código do cliente fique poluído com várias estruturas de seleção (“Ifs”) testando o tipo do objeto a ser invocado para chamar o método apropriado.
O Command gera uma maior flexibilidade na arquitetura do sistema, uma vez que permite a adição de novas funcionalidades (comandos) sem a necessidade de mudar o design da arquitetura. Outro ponto positivo do padrão Command é que ele posibilita desfazer as ações realizadas por um comando. Para isso, é necessário implementar um método no comando (geralmente chamado de undo) que realize as operações contrárias as operações realizadas quando o comando foi invocado.
Um ponto negativo para esse padrão é que ele deixa o design da aplicação
“procedural”, isto é, orientado a ações.

Exemplo de Uso do padrão Command

No exemplo dessa subseção, será mostrada a implementação do padrão Command, para se modelar a ação de se ligar um aparelho de Televisão.

Para se implementar o padrão Command, primeiro é necessário criar uma interface que contenha os métodos comuns para um comando. Esses métodos são o execute, para executar a ação do comando e se for necessário, o método undo para desfazer a ação realizada. O código dessa interface pode ser visto abaixo:

/** todo comando implementa a mesma interface
* que consiste de apenas um metodo */
public interface Command {
public void execute();
public void undo();
}

Padrão OBSERVER - Aula 21 e 22

Padrão OBSERVER

O assunto a ser tratado hoje, será o Padrão Observer, segundo GOF "Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente."

Ele é indicado para tratar situações de dependência. Sua utilização oferece o benefício de se relacionar duas ou mais classes sem criar um vínculo explícito entre elas.

O padrão Observer abstrai a relação dos objetos definindo-os como Observer e Subject.
Observer são objetos que ficam aguardando por uma mudança no estado de determinado objetos para poderem tomar uma ação. Subject são os objetos que estão sendo observados.
Olhando para nossa situação, o objeto Venda é um Subject e a notificação ao usuário e envio de arquivo são os Observers.

Como garantir que objetos que dependem de outro. Objeto fiquem em dia com mudanças naquele objeto?
– Como fazer com que os observadores tomem conhecimento do objeto de interesse?
– Como fazer com que o objeto de interesse atualize os observadores quando seu estado mudar?
• Possíveis riscos
– Relacionamento (bidirecional) implica alto acoplamento.
– Como podemos eliminar o relacionamento bidirecional?

Padrão Singleton - Aula 20

Padrão singleton

Como vimos durante a aula esplanada pelo Professor João Bosco de Barro, a respeito do padrão Singleton que segundo GOF, "Garante que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela."

É necessário para algumas classes conter uma, e apenas uma, instância. Por exemplo, embora possam existir muitas impressoras em um sistema, deveria haver somente um spooler de impressoras. Da mesma forma, deveria haver somente um sistema de arquivos e um gerenciador de janelas. Um filtro digital terá somente um conversor A/D. Um sistema de contabilidade será dedicado a servir somente a uma companhia.
Como garantimos que uma classe tenha somente uma instância e que essa instância seja facilmente acessível? Uma variável global torna um objeto acessível, mas não impede você de instanciar múltiplos objetos.
Uma solução melhor seria tornar a própria classe responsável por manter o controle de sua única instância. A classe pode garantir que nenhuma outra instância seja criada (pela interceptação das solicitações para criação de novos objetos), bem como pode fornecer um meio para acessar sua única instância. Este é o padrão Singleton.

Quando usar Singleton?
Use o padrão Singleton quando:

For preciso haver apenas uma instância de uma classe, e essa instância tiver que dar acesso aos clientes através de um ponto bem conhecido;
A única instância tiver de ser extensível através de subclasses, possibilitando aos clientes usar uma instância estendida sem alterar o seu código.

Conseqüências:

O padrão Singleton apresenta vários benefícios:
Acesso controlado à instância única: Como a classe Singleton encapsula a sua única instância, possui controle total sobre como e quando os clientes a acessam.
Espaço de nomes reduzido: O padrão Singleton representa uma melhoria em relação ao uso de variáveis globais. Ele evita a poluição do espaço de nomes com variáveis globais que armazenam instâncias únicas.
Permite um refinamento de operações e da representação: A classe Singleton pode ter subclasses e é fácil configurar uma aplicação com uma instância dessa classe estendida. Você pode configurar a aplicação com uma instância da classe de que necessita em tempo de execução.
Permite um número variável de instâncias: O padrão torna fácil mudar de idéia, permitindo mais de uma instância da classe Singleton. Além disso, você pode usar a mesma abordagem para controlar o número de instâncias que a aplicação utiliza. Somente a operação que permite acesso à instância de Singleton necessita ser mudada.
Mais flexível do que operações de classe: Uma outra maneira de empacotar a funcionalidade de um singleton é usando operações de classe. Porém, tal técnica torna difícil mudar um projeto para permitir mais que uma instância de uma classe.

Padrão ADAPTER - Aula 20

Nome do Padrão: ADAPTER

Como vimos durante a aula, O Objetivo do padrão Adapter segundo "GOF" é converter a interface de uma classe em outra interface esperada pelos clientes. Adapter permite a comunicação entre classes que não poderiam trabalhar juntas devido à incompatibilidade de suas interfaces .

Problema: Como enfrentar modificações de bibliotecas terceirizadas, mantendo nossa aplicação sincronizada quanto às alterações essenciais nas funcionalidade e arquitetura.
Solução: Utilizando classes que trabalharão na camada intermediária entre a aplicação cliente e a biblioteca em si. Executando alterações quanto às chamadas de operações para uma correta operação.

Dois tipos de Adapter

Adaptador de Objetos.
Criamos uma classe intermediaria que servirá como interface entre as chamadas do código cliente e o código da classe. Ele trabalhará basicamente como um "filtro" para as chamadas. Chamamos essa forma de COMPOSIÇÃO.

Adaptador de Classes.

Criamos uma classe que HERDARÁ da classe utilitária e sobrescrevemos ou recriamos o método chamado. Chamamos essa forma de HERANÇA.
A escolha da abordagem de implementação do Adapterserá uma tomada de decisão do Arquiteto de Software e dependerá do contexto da aplicação. Muita cautela nessa hora!

Quando Usar o Padrão Adapter:

Você quiser usar uma classe existente, mas sua interface não corresponder à interface de que necessita;
Você quiser criar uma classe reutilizável que coopere com classes não-relacionadas ou não-previstas, ou seja, classes que não necessariamente tenham interfaces compatíveis; (Somente para adaptadores de objetos).

Você precisar usar várias subclasses existentes, porém, for impraticável adaptar essas interfaces criando subclasses para cada uma. Um adaptador de objeto pode adaptar a interface da sua classe-mãe.

Aula 19 - Introdução de Padroes GOF

Primeiramente iremos tratar a respeito da idéia do conceito de padrões.
O que é um Padrão?
Podemos dizer que Padrão é: Compromisso documentado, utilizado em comum e repetidas vezes pelas pessoas relacionadas com um determinado trabalho.
Então segundo Gamma, Helm, Vlissides & Johnson, criadores do padrão GOF. descreveram da seguinte forma o conceito:
"Os padrões de projeto são descrições de objetos que
se comunicam e classes que são customizadas para
resolver um problema genérico de design em um
contexto específico"
Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução.

Aprender a programar bem com orientação a objetos
Os 23 padrões de projeto “clássicos” utilizam as
melhores práticas em OO para atingir os resultados
desejados
Padrões "GoF" organizados nas suas famílias:

Padrões de criação
Abstract Factory
Builder
Factory Method
Prototype
Singleton



Referencias Bibliográficas
http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software - 14/04/2008 23h31