Padrões de Design Orientado a Objetos

Design Patterns

História

• O nome “Design Patterns" foi cunhado por Christopher Alexander quando ele propôs a criação de catálogos de padrões para arquitetura em seu livro:

“A Pattern Language: Towns, Buildings, Construction”(1977).

História

“Cada padrão descreve um problema que ocorre freqüentemente em seu ambiente, e então descreve o cerne da solução para aquele problema, de um modo tal que você pode usar esta solução milhões de vezes, sem nunca fazer a mesma coisa repetida”

Christopher Alexander

História

• Idealmente um padrão deve possuir as seguintes características: – Encapsulamento: um padrão encapsula

um problema/solução bem definido. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.

História

– Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão.

– Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.

História

– 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.

– Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.

História

– 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.

História

• Em sua obra, Alexander 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.

História

– 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.

História

– 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.

História

• A partir dos conceitos criados por Alexander, Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação (Construção de janelas na linguagem Smalltalk, 1988).

• Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento desta idéia.

História

• Em 1995 o movimento ao redor de padrões de projeto ganhou popularidade com o livro: “Design Patterns: Elements of Reusable Object-Oriented Software”.

• Os autores desse livro são Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF".

Porque Utilizar Design Patterns?

• Criação de soluções de software:– Elegantes– Simples– Reutilizáveis– Fácil manutenção

Padrões GoF

• Os padrões GoF são organizados nas seguintes famílias:

• Criacionais– Tornam um sistema independente de

como seus objetos são criados, compostos e representados

Padrões GoF

• Estruturais– Tratam de compor classes e objetos para

formar estruturas grandes e complexas

• Comportamentais– Tratam de algoritmos e como atribuir

responsabilidades entre objetos

Família dos Padrões Criacionais

• Abstract Factory– Permite a criação de famílias de objetos

relacionados ou dependentes, através de uma única interface e sem que a classe concreta seja especificada.

• Builder– permite a separação da construção de um objeto

complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.

Família dos Padrões Criacionais

• Factory Method– Fornece uma interface para criação de

famílias de objetos relacionados ou dependentes, sem especificar suas classes concretas.

• Prototype – Permite a criação de objetos a partir de um

modelo original, ou protótipo (clonar objetos instanciados em memória).

Família dos Padrões Criacionais

• Singleton– Permite que uma classe possua apenas

uma instância. Isso permite um único ponto global de acesso á essa instância.

Família dos Padrões Estruturais

• Adapter– Permite que classes com interfaces

incompatíveis possam interagir.

• Bridge– utilizado quando é desejável que uma

interface (abstração) possa variar independentemente das suas implementações.

Família dos Padrões Estruturais

• Composite– Utilizado para representar um objeto que é

constituído pela composição de objetos similares a ele.

• Decorator– Utilizado para adicionar responsabilidades

aos objetos dinamicamente.

Família dos Padrões Estruturais

• Façade– disponibiliza uma interface para uma

grande quantidade de funcionalidades de uma API

• Flyweight– apropriado quando vários objetos devem

ser manipulados, e esses não suportam dados adicionais.

Família dos Padrões Estruturais

• Proxy– Encapsula um objeto através de um outro

objeto que possui a mesma interface, de forma que o segundo objeto, conhecido como “Proxy”, controla o acesso ao primeiro, que é o objeto real.

Família dos Padrões Comportamentais

• Chain of Responsability– Evita o acoplamento do remetente de uma

solicitação ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar a solicitação

• Command– Encapsular uma solicitação como um objeto,

desta forma permitindo parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas.

Família dos Padrões Comportamentais

• Interpreter

• Iterator– permite a "iteração" e um modo de acesso

a elementos de um agregado de objetos, seqüencialmente, sem exposição de estruturas internas.

Família dos Padrões Comportamentais

• Mediator– Desacopla e gerencia as colaborações

entre um grupo de objetos.

• Memento – Define como salvar o estado de uma

instância de uma classe e restaurá-la depois.

Família dos Padrões Comportamentais

• Observer – Permite que quando um objeto mude seu

estado, todos seus dependentes sejam notificados e atualizados automaticamente.

• State– Permite que um objeto altere o seu

comportamento quando o seu estado muda.

Família dos Padrões Comportamentais

• Strategy– Este padrão permite que o algoritmo possa variar

independentemente dos clientes que o utilizam .

• Template Method

• Visitor– permite definir novas operações sem alterar as

classes dos elementos sobre os quais opera. Adiciona funções polimórficas a uma classe de maneira não invasiva.

Considerações Finais

• Os padrões de projeto não devem ser vistos como a salvação universal para o problema do desenvolvimento de software nem ser posto de lado como uma coisa inútil. Eles apenas fornecem uma relação de soluções comuns que são usadas no mundo real das aplicações comerciais, soluções que já foram provadas e aprovadas em diferentes projetos de software.

Considerações Finais

• Conhecer os padrões de projeto pode ser muito interessante mas saber como aplicá-los aos seus projetos é o que realmente vai fazer a diferença.

Bibliografia

• Enterprise Solution Patterns Using Microsoft .NET, Microsoft, 2007

• Introduction to Design Patterns in C#, James W Cooper, 2002

• Core J2EE Patterns, Alur, Crupi, Malks, 2004

Bibliografia

• Wikipedia– http://en.wikipedia.org/wiki/Christopher_Ale

xander#Architecture

– http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software

– http://en.wikipedia.org/wiki/A_Pattern_Language