Desing Patterns – Introdução

Design Patterns (ou padrões de projeto) representam as melhores práticas utilizada por desenvolvedores experientes quando se trata de projetos orientados a objetos.
Neste post, teremos uma breve explicação sobre design patterns, e uma listagem com 23 exemplos clássicos, listados no livro GoF (Gang of Four).

Design Patterns, em resumo, são soluções recorrentes para problemas específicos. Ou seja, cada padrão descreve uma solução para determinado problema em específico. Não devemos utilizar determinado padrão se não tivermos o problema para qual ele foi elaborado.

Percebendo que, na maioria dos projetos orientados a objetos, os problemas que ocorrem muitas vezes são recorrentes, um grupo de quatro desenvolvedores decidiu elaborar uma solução ideal para aquele problema e registrar isso, para que futuros projetos utilizassem a mesma solução. Este grupo ficou conhecido como Gang of Four (GoF), e seus registros de padrões estão descritos no livro Padrões de Projeto – Soluções Reutilizáveis de Software Orientado a Objetos.

Livro GoF

Este livro ficou especialmente famoso por ser o primeiro (ou um dos primeiros) registros de padrões de projeto orientado a objetos. O livro descreve, para cada padrão, seu nome, o problema, como solucionar e as consequências de se aplicar determinado padrão.
Os exemplos do livro estão em C++ ou Smalltalk, mas podem ser utilizados em qualquer liguagem orientada a objetos.

Em resumo:
* Soluções “simples e elegantes” para problemas específicos
* Não necessitam de nenhuma “mágica” ou biblioteca em específico, apenas padrões de orientação a objetos
* São independentes de linguagem de programação

Neste livro, os padrões são separados em três propósitos: criacionais, estruturais e comportamentais. São separados também em 2 escopos: classe e objeto:

gofPatterns

Abaixo, um resumo de cada um dos design patterns do livro:

Criacional

Singleton
Garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela

Abstract Factory
Prover interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas

Builder
Separar a construção de objeto complexo da representação para criar representações diferentes com mesmo processo

Prototype
Especificar tipos a criar usando uma instância como protótipo e criar novos objetos ao copiar este protótipo

Factory Method
Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar

 

Estrutural

Decorator
Anexar responsabilidades adicionais a um objeto dinamicamente

Proxy
Prover um substituto ou ponto através do qual um objeto possa controlar o acesso a outro

Façade
Oferecer uma interface única de nível mais elevado para um conjunto de interfaces de um subsistema

Flyweight
Usar compartilhamento para suportar eficientemente grandes quantidades de objetos complexos

Composite
Permitir o tratamento de objetos individuais e composições desses objetos de maneira uniforme

Bridge
Desacoplar uma abstração de sua implementação para que os dois possam variar independentemente

Adapter
Converter a interface de uma classe em outra interface esperada pelos clientes.

 

Comportamental

Template Method
Definir o esqueleto de um algoritmo dentro de uma operação, deixando alguns passos a serem preenchidos pelas subclasses

Visitor
Representar uma operação a ser realizada sobre os elementos de uma estrutura de objetos

Command
Encapsular requisição como objeto, para clientes parametrizarem diferentes requisições, filas, e suportar operações reversíveis

Strategy
Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis

Chain of Responsibility
Compor objetos em cascata para, através dela, delegar uma requisição até que um objeto a sirva

Iterator
Prover uma maneira de acessar elementos de um objeto agregado sequencialmente sem expor sua representação interna

Mediator
Definir um objeto que encapsula a forma como um conjunto de objetos interagem

Memento
Externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente

Interpreter
Dada uma linguagem, definir uma representação para sua gramática junto com um interpretador

State
Permitir a um objeto alterar o seu comportamento quanto o seu estado interno mudar

Observer
Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, os seus dependentes sejam notificados e atualizados automaticamente

 

Existem outros Design Patterns?

Sim! Existem vários outros design patterns. O que estamos vendo aqui são apenas os 23 padrões descritos neste livro, conhecidos como GoF.

Por exemplo, para a certificação de arquiteto java, além dos 23 padrões “GoF”, o candidato precisa conhecer todos os padrões do livro “Core JEE Patterns“, que ilustra outros padrões, mais voltados para a arquitetura JEE.

Livro Core JEE Patterns

 

Recomendo fortemente a leitura destes livros para quem tem interesse em conhecer melhor cada um dos padrões.

Nos próximos posts, vou tentar explicar cada um dos padrões GoF.

Referências:

Padrões de Projeto – Soluções Reutilizáveis de Software Orientado a Objetos.

GoF Patterns

Core JEE Patterns

 

Um abraço

Deixe um Comentário

0 Comentários.

Deixe um Comentário


NOTA - Você pode usar estesHTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>