Introdução
Conhecer herança, polimorfismo e abstração não o fazem um bom desenvolvedor. Muitas pessoas já passaram pelos mesmos problemas que você está passando ou vai passar e saber utilizar este conhecimento é um início para o caminho das pedras.
Tem gente que pensa que saber fazer if, for, while já é suficiente para se dizer desenvolvedor. É necessário pensar de forma padronizada levando em consideração desempenho, portabilidade, fácil manutenção, fácil compreensão e muitos outros pontos que poderia ser um bom e grande post.
Este post visa iniciar os estudos nos padrões de projetos para obter uma visão geral. Eu sei que escrevo bastante, mas eu tento passar o máximo de informação em menos linhas possíveis. O que acontece é que existe muitas informações a serem passadas… mania de desenvolvedor, hehehehe.
Lembre-se: Um padrão não foi inventado do nada, foi pensado, modelado e utilizado inumeras vezes com resultado de sucesso. Se você estiver tendo problemas com isto, repense, talvez não esteja fazendo da forma correta.
Por onde começar?
Iniciaremos o estudo em cima dos 23 padrões de projetos clássicos do GoF. Não existirá uma sequência definida e sim os mais simples de compreender primeiro.
Abaixo segue a classificação dos 23 padrões segundo o GoF.
Interfaces: Adapter, Facade, Composite, Bridge
Responsabilidade: Singleton, Observer, Mediator, Proxy, Chain Of Responsibility, Flyweight
Construção: Builder, Factory Method, Abstract Factory, Prototype, Memento
Operações: Template Method, State, Strategy, Command, Interpreter
Extensões: Decorator, Interator, Visitor
Veremos, adiante, o que são, como funciona e como implementar estes padrões. Cada um deles resolvem um problema específico, é preciso entender porque, quando e como aplicá-los.
Objetivos dos 23 padrões de projetos
Abaixo veremos, de forma resumida, os objetivos de todos eles, segundo o GoF.
1. Adapter: Converter a interface de uma classe em outra interface esperada pelos clientes.
2. Façade: Oferecer uma interface única de nível mais elevado para um conjunto de interfaces de um subsistema.
3. Composite: Permitir o tratamento de objetos individuais e composições desses objetos de maneira uniforme.
4. Bridge: Desacoplar uma abstração de sua implementação para que os dois possam variar independentemente.
5. Singleton: Garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela.
6. 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.
7. Mediator: Definir um objeto que encapsula a forma como um conjunto de objetos interagem.
8. Proxy: Prover um substituto ou ponto através do qual um objeto
possa controlar o acesso a outro.
9. Chain of Responsibility: Compor objetos em cascata para, através dela, delegar uma requisição até que um objeto a sirva.
10. Flyweight: Usar compartilhamento para suportar eficientemente grandes quantidades de objetos complexos.
11. Builder: Separar a construção de objeto complexo da representação para criar representações diferentes com mesmo processo.
12. Factory Method: Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar.
13. Abstract Factory: Prover interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.
14. Prototype: Especificar tipos a criar usando uma instância como protótipo e criar novos objetos ao copiar este protótipo.
15. Memento: Externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente.
16. Template Method: Definir o esqueleto de um algoritmo dentro de uma operação, deixando alguns passos a serem preenchidos pelas subclasses.
17. State: Permitir a um objeto alterar o seu comportamento quanto o seu estado interno mudar.
18. Strategy: Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis.
19. Command: Encapsular requisição como objeto, para clientes parametrizarem diferentes requisições, filas, e suportar operações reversíveis.
20. Interpreter: Dada uma linguagem, definir uma representação para sua gramática junto com um interpretador.
21. Decorator: Anexar responsabilidades adicionais a um objeto dinamicamente.
22. Iterator: Prover uma maneira de acessar elementos de um objeto agregado seqüencialmente sem expor sua representação interna.
23. Visitor: Representar uma operação a ser realizada sobre os elementos de uma estrutura de objetos.
Soluções para problemas comuns que os padrões de projeto evitam
Especificação explicita de classe na criação de objetos: O sistema está preso a uma implementação específica.
Solução: criar objetos indiretamente com Abstract Factory, Factory Method ou Prototype.
Dependência em operações específicas: O sistema só tem uma forma de satisfazer uma requisição.
Solução: evitar ações “hard-coded” com Chain of Responsibility ou Command.
Dependência em plataforma de hardware ou software: O software precisa ser portado a outras plataformas.
Solução: limitar dependências com Abstract Factory ou Bridge.
Dependência em representações ou implementações de objetos: Clientes que sabem como um objeto é implementado, representado ou armazenado podem precisar serem alterados se o objeto mudar.
Solução: isolar cliente com Abstract Factory, Bridge, Memento ou Proxy.
Dependências de algoritmo: Mudanças de algoritmo são freqüentes. Objetos que dependem de um algoritmo precisam mudar quando o algoritmo mudar.
Solução: isolá-los com Builder, Iterator, Strategy, Template Method ou Visitor
Forte acoplamento: Classes fortemente acopladas são difíceis de reusar, testar, manter, etc.
Solução: enfraquecer o acoplamento com Abstract Factory, Bridge, Chain of Responsibility, Command, Façade, Mediator ou Observer.
Extensão de funcionalidade através de subclasses: Herança é difícil de usar na sua forma correta e a composição dificulta compreensão.
Solução: usar padrões que implementam bem herança e composição como Bridge, Chain of Responsibility, Composite, Decorator, Observer ou Strategy.
Incapacidade de alterar classes convenientemente: Classes inaccessíveis, incompreensíveis ou difíceis de alterar.
Solução: usar Adapter, Decorator ou Visitor.
Tipos de software
Vamos entender as prioridades de padrões de projetos nos tipos comuns de softwares.
Aplicações: Softwares especialistas de modo geral.
Prioridades: reuso interno, manutenção e extensão.
Toolkits, APIs, bibliotecas: Conjunto de classes reutilizáveis de propósito geral. Não impõem design.
Prioridade: amplo reuso de código.
Frameworks: Dita a arquitetura da aplicação. Requer que usuário aprenda o framework e inclua código e configuração.
Prioridade: amplo reuso de design.
Geralmente são fortemente baseados em padrões. Quem conheçe os padrões entende o framework mais facilmente.
Conclusão
O caminho inicial é grande, eu sei, mas é necessário iniciar de algum lugar. Existem padrões de projeto sendo criados o tempo todo, é necessário entender os clássicos antes de se aventurar nos mais novos.
Existem muitos problemas já resolvidos, não vale a pena perder tempo inventando uma forma “rápida” de resolver, vamos usar o conhecimento dos mais experientes. 
Referência
Erich Gamma et al. Design Patterns: Elements of Reusable
Object-oriented Software. Addison-Wesley, 1995.
METSKER, Steven John. Design Patterns Java Workbook. Addison-Wesley, 2002.
Abraços a todos e até a próxima.
“A maioria das pessoas tem êxito porque se determinou a tê-lo. Gente medíocre às vezes consegue um sucesso notável simplesmente porque não sabe quando parar.” George Allen, treinador de futebol americado.
