Design Patterns

TECNOLOGIA EM REDES DE COMPUTADORES

RCN04S1

PROGRAMAÇÃO ORIENTADA A OBJETOS

Professor: Marcelo de Queiroz Leite

Manaus – 2014

DESIGN PATTERNS

INTRODUÇÃO

Design patterns (Padrões de projeto) são soluções de templates abstratas de alto nível. Pense nelas como um “blue print” (desenho técnico ou documentação de uma arquitetura, etc.) para soluções e não como uma solução por si própria. Você não achará um framework que você poderá simplesmente aplicar para a sua aplicação; ao invés disso, você chegará ao design patterns através da fatoração do seu código e generalização do seu problema.

Design patterns não são somente aplicados em desenvolvimento de software; design patterns podem ser encontrados em diversas áreas da vida, da engenharia até da arquitetura. Em fato, foi o arquiteto Christopher Alexander que introduziu a ideia de patterns em 1970 para construir um vocabulário comum para discussões sobre design. Ele escreveu:

Cada pattern descreve um problema que ocorre várias vezes ao nosso redor e com isso, descrevem a solução para o problema de uma maneira que você pode usar essa solução diversas vezes sem ter que fazer a mesma coisa duas ou mais vezes.

 

O que são Design Patterns?

Design patterns (padrões de projeto) surgiram com a motivação de ajudar a solucionar problemas que ocorrem frequentemente, e, se usados com bom senso, podem se tornar ferramentas poderosas para qualquer desenvolvedor de software, uma vez que já foram testadas, utilizadas e aprimoradas a partir da experiência e conhecimento de outros programadores.

Preparamos um post explicando o que são design patterns e seus princípios comuns, baseado no livro “Professional ASP.NET Design Patterns” de Scott Millett.

Origens

As origens do design patterns que prevalecem hoje na arquitetura de software nasceram das experiências e conhecimento dos programadores utilizando a programação orientada a objeto.

Christopher Alexander 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, frequentemente 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.

O conjunto dos mais conhecidos designs patterns estão catalogados no livro chamado “Design Patterns: Elements of Reusable Object-Oriented Software”, mais conhecido como “Design Patterns Bible”. Esse livro foi escrito por Erich Hamma, Richard Helm, Ralph Johson e John Vlissdes, mais conhecidos como “Gang of Four” ou simplesmente "GoF".

Padrões GoF

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.

Padrões "GoF" organizados nas suas 3 famílias:

-PADRÃO CRIAÇÃO

Abstract factory: Fornecer uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.

Builder: Separa-se a construção de um objeto complexo da sua representação, permitindo que o mesmo processo de construção para criar várias representações.

Factory method: Definir uma interface para criar um único objeto, mas deixar as subclasses decidirem qual classe instanciar. Factory Method permite a instanciação de classe adiar para subclasses (injeção de dependência).

Lazy initialization: Tática de atrasar a criação de um objeto, o cálculo de um valor, ou algum outro processo caro até a primeira vez que é necessário. Este padrão aparece no catálogo GoF como "procuração virtual", uma estratégia de implementação para o proxy padrão.

Multiton: Certifique-se de uma classe nomeou apenas exemplos, e fornecer o ponto global de acesso a eles.

Object pool: Evite aquisição cara e liberação de recursos através da reciclagem de objetos que não estão mais em uso. Pode ser considerada uma generalização do pool de conexão e thread pool padrões.

Prototype: Especificar os tipos de objetos para criar usando uma instância protótipo e criar novos objetos copiando este protótipo.

Resource acquisition is initialization: Certifique-se de que os recursos sejam devidamente lançado, amarrando-os para a vida útil de objetos adequados.

Singleton: Certifique-se de uma classe tem apenas uma instância e fornecer um ponto global de acesso a ela.

- PADRÃO ESTRUTURAL

Adapter ou Wrapper ou Translator: Converter a interface de uma classe para outra interface de clientes esperam. Um adaptador permite que classes de trabalhar juntos que não poderia de outra forma, porque de interfaces incompatíveis. O padrão de integração empresarial equivalente é o tradutor.

Ponte: Dissociar uma abstração de sua implementação permitindo que os dois variar independentemente.

Composite: Compor objetos em estruturas de árvore para representar hierarquias parte-todo. Composite permite que clientes tratem objetos individuais e composições de objetos de maneira uniforme.

Decorator: Anexar responsabilidades adicionais a um objeto dinamicamente mantendo a mesma interface. Decoradores fornecem uma alternativa flexível para subclasse para estender a funcionalidade.

Fachada: Fornecer uma interface unificada para um conjunto de interfaces em um subsistema. Fachada define uma interface de nível mais elevado que faz com que o subsistema mais fácil de usar.

Mosca: Usar compartilhamento para suportar grandes quantidades de objetos similares de forma eficiente.

Front Controller: O padrão refere-se à concepção de aplicações de web. Ele fornece um ponto de entrada centralizada para o tratamento dos pedidos.

Módulo: Grupo de vários elementos relacionados, tais como aulas, singletons, métodos, utilizados globalmente, em uma única entidade conceitual.

Proxy: Fornecer um substituto ou espaço reservado para outro objeto para controlar o acesso a ele.

Duplo: Permite modelar herança múltipla em linguagens de programação que não suportam este recurso.

-PADRÃO COMPORTAMENTAL

Blackboard: Observador generalizada, que permite que vários leitores e escritores. Comunica-se todo o sistema de informação.

Cadeia de responsabilidade: Evite o acoplamento do remetente de uma solicitação ao seu receptor, dando mais de um objeto a chance de lidar com o pedido. Acorrentar os objetos que recebem e passam a solicitação ao longo da cadeia até que um objeto manipula-lo.

Comando: Encapsular uma solicitação como um objeto, permitindo assim parametrizar clientes com pedidos diferentes, a fila ou fazer solicitações, e apoiar as operações que podem ser desfeitas.

Intérprete: Dada uma linguagem, definir uma representação para sua gramática juntamente com um interpretador que usa a representação para interpretar sentenças na língua.

Iterator: Fornecer uma maneira de acessar os elementos de um agregado objeto sequencialmente sem expor sua representação subjacente.

Mediador: Definir um objeto que encapsula como um conjunto de objetos interagem. Mediator promove o acoplamento fraco, mantendo objetos de se referir uns aos outros de forma explícita, e que lhe permite variar a sua interação de forma independente.

Memento: Sem violar o encapsulamento, captura e externaliza o estado interno de um objeto permitindo que o objeto a ser restaurado para este estado mais tarde.

Objeto nulo: Evite referências nulas, fornecendo um objeto padrão.

Observer ou publicação / assinatura: Definir uma dependência um-para-muitos entre objetos, onde uma mudança de estado no resultado de um objeto em todos os seus dependentes sendo notificados e atualizados automaticamente.

Servo: Definir a funcionalidade comum para um grupo de aulas.

Especificação: Recombina lógica de negócios em uma moda booleana.

Estado: Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto aparecerá para mudar sua classe.

Utilidade

O valor do design patterns reside no fato que eles são soluções que foram utilizadas e testadas, o que nos dá confiança em sua eficácia.

Design patterns focam na reutilização de soluções. Todos os problemas não são iguais, mas se você puder “quebrar” o problema e achar similaridades com problemas que você já resolveu antes, você pode aplicar essas soluções. Depois de décadas de programação orientada a objeto, a maioria dos problemas que você encontrará já terão sido resolvidas no passado, e haverá um pattern disponível para ajudar você na implementação da solução. Mesmo se você acredita que o seu problema é único, ao quebrá-lo em pequenas partes, você será capaz de generalizá-lo o suficiente para encontrar a solução apropriada.

O nome dos designs patterns são úteis porque refletem o seu comportamento e propósito, e fornecem um vocabulário comum em um brainstorming de solução. É muito mais fácil falarmos em termos do nome do pattern do que detalhar sobre como essa implementação deveria funcionar.

O que eles não são

Design patterns não são a bala de prata (solução de todos os problemas). Você deve ter o entendimento geral do seu problema, generalizá-lo e então aplicar o pattern apropriado para a solução desse problema. Porém, nem todos os problemas requerem um design pattern. É verdade que o design pattern pode ajudar a tornar problemas complexos em problemas simples, porém eles também podem tornar problemas simples em problemas complexos.

 

CONCLUSÃO

A criação de uma linguagem para a comunidade de desenvolvedores em orientação a objetos era uma necessidade antiga. A UML realmente incorporou muitos recursos com dão a linguagem uma extensibilidade muito grande.

A organização da modelagem em visões e a divisão dos diagramas especificando características estáticas e dinâmicas do sistema tornou a UML fácil de ser utilizada e fez com que qualquer tipo de comportamento possa ser visualizado em diagramas.

A modelagem visual orientada a objetos agora possui um padrão, e esse padrão é extremamente simples de ser escrito a mão, sendo robusto para especificar e descrever a grande maioria das funções, relacionamentos e técnicas de desenvolvimento orientado a objetos que hoje são utilizados. Novas técnicas irão surgir e a UML também estará preparada já que tudo estará baseado nas ideias elementares da orientação a objetos.

Sem dúvida alguma a UML facilitará às grandes empresas de desenvolvimento de software uma maior comunicação e aproveitamento dos modelos desenvolvidos pelos seus vários analistas envolvidos no processo de produção de software já que a linguagem que será utilizada por todos será a mesma, acabando assim com qualquer problema de interpretação e mal entendimento de modelos criados por outros desenvolvedores. Os modelos criados hoje poderão ser facilmente analisados por futuras gerações de desenvolvedores acabando com a diversidade de tipos de nomenclaturas de modelos, o grande empecilho do desenvolvimento de softwares orientados a objetos.