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.
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:
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.
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.
Um abraço
0 Comentários.