Design Patterns: na teoria e na prática

Em 1994, antes mesmo de James Gosling apresentar a linguagem de programação Java para o mundo, Erich Gamma,Richard Helm,Ralph Johnsone John Vlissides, também conhecidos como “The Gang of Four” lançaram o livro “Design Patterns: Elements of Reusable Object-Oriented Software”. Para muitos evangelistas da linguagem orientada a objetos, esse foi o divisor de águas entre programar orientado a objetos e compreender o conceito real de programar orientado a objetos.

Nesse livro foram catalogados vinte e três padrões de projeto divididos em três categorias:

• Padrões de criação – Abstract Factory, Builder, Factory Method, Prototype e Singleton;
• Padrões estruturais– Adapter, Bridge,Composite, Decorator, Facade, Flyweight e Proxy;
• Padrões comportamentais– Chain of responsibility, Command, Interpreter,Iterator, Mediator, Memento, Observer, State, Strategy, Template method e Visitor.

Atualmente, quase 100% dos sistemas desenvolvidos em Java com o padrão MVC utilizam-se de frameworks de apoio, sendo mais comuns o JSF 2 para as camadas de apresentação e o Hibernate para a camada de persistência. Isso sem falar que dentro de uma aplicação, na camada de negócio, pode-se incluir o Spring como apoio para injeção de dependência e inversão de controle (IoC) ou o próprio EJB 3 aliado ao CDI para obter a mesma eficiência do Spring na parte de IoC.

Esses frameworks acabam “mascarando” boa parte da complexidade do que é programar orientado a objetos, fazendo com que o desenvolvedor se limite a implementar métodos, muitas vezes apenas encaixando-os nos pontos certos, ligando uma ponta à outra. É isso mesmo. Ele deixa de ser um desenvolvedor e se torna um implementador.

O trecho a seguir toma uma afirmação do próprio livro (Design Patterns: Elements of Reusable Object-Oriented Software), coincidentemente já quase que prevendo um fato que ocorre nos dias de hoje:

“Um framework dita a arquitetura da sua aplicação. Ele define a arquitetura de forma geral, sua subdivisão em classes e objetos, a responsabilidade entre eles, como os objetos colaboram. Um framework predefine esses padrões de desenvolvimento para você. O desenvolvedor/implementador pode se concentrar em detalhes da aplicação… GoF Pág. 26.”.

A intenção do uso de um framework é sem dúvida alguma acelerar o desenvolvimento e facilitar a manutenção do sistema, mas, por outro lado, muitos desenvolvedores acabam se tornando especialistas em determinado framework, mas inexperientes em programar orientado a objetos em sua plenitude.

A consequência disso é que quando surge um problema que requer o mínimo de elegância na solução, acaba-se adotando uma estratégia procedural dentro de uma aplicação que deveria ser por si só totalmente orientada a objetos.

Com base nisso, a ideia deste artigo é mostrar como identificar um problema e reconhecer o design pattern que melhor se encaixa como solução. O primeiro tópico apresentará o design pattern Chain Of Responsibility. Esse padrão possui um alto grau de polimorfismo, é capaz de automatizar um processo e representa muito bem o quarto princípio da programação orientada a objetos: o Princípio da Segregação de Interfaces. Em seguida será apresentado o design pattern Strategy. Esse padrão é capaz de impor um baixo acoplamento e representa muito bem a boa prática de programar voltado a interface. Você notará que em nenhum dos tópicos apresentados será cogitado o uso de qualquer framework. O objetivo disso é ensinar ao leitor como id ...