Artigos Java Design Patterns: na teoria e na prática
Por que eu devo ler este artigo:

Programadores mais novos atualmente se preocupam em tornarem-se especialistas em determinado framework, ignorando a complexidade envolvida por trás e consequentemente deixam de programar orientado a objetos em total plenitude, limitando-se apenas a criar trechos de código que se conectam e são executados por esses mesmos frameworks. A consequência disso é a recorrência cada vez maior a estratégias procedurais para resolver problemas nem tanto complexos.

É muito fácil encontrar uma funcionalidade que pode conter três ou mais condições para obter um resultado dentro de qualquer sistema, e que muitas vezes na pressa, fazem com que o desenvolvedor opte em criar um “encadeamento” (IF-ELSE), ignorando completamente um dos princípios básicos da OO, a Abstração, muitas vezes forçando um alto acoplamento. Dito isso, este artigo demonstrará como evitar o alto acoplamento, identificando um problema dentro de um cenário apresentado e aplicando o design pattern correto para solucioná-lo, sem o auxílio de qualquer framework.

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 identificar um problema e mostrar alternativas elegantes para solucioná-lo.

Chain Of Responsibility

É o primeiro na lista dos padrões comportamentais, sendo extremamente fácil de implementar e que pode ser muito útil como solução adotada dentro de um sistema corporativo, pois impõe um alto grau de coerência ao código, força um baixo acoplamento, utiliza muito bem recursos de polimorfismo e é capaz de automatizar um processo sem encadeamentos desnecessários.

Esse design pattern promete acabar com o encadeamento excessivo, que é visto como uma das principais causas da ocorrência de alto acoplamento e até mesmo criando “baixa coerência” no código por conta de encadeamentos desnecessários e sem sentido.

O design pattern Chain Of Responsibility permite determinar quem será o objeto que irá tratar uma requisição em tempo de execução. Dessa forma, cada objeto pode tratar ou passar a responsabilidade para o próximo, construindo uma cadeia de responsabilidades.

O trecho a seguir toma a definição do livro Patterns: Elements of Reusable Object-Oriented Software em relação à intenção desse padrão: “Evitar o acoplamento do remetente de uma solicitação. Encadear os objetos receptores, passando a solicitação ao longo da cadeia até que um objeto a trate... GoF Pág. 212.”

Essa é a grande motivação para o uso desse pattern: acabar com as estruturas de decisão, criando uma cadeia de objetos. A responsabilidade é passada entre eles até finalmente ser tratada por quem tiver a devida competência.

Características do Chain Of Responsibility

Em um sistema orientado a objetos, estes interagem entre si. Como já foi ressaltada ant ...

Quer ler esse conteúdo completo? Tenha acesso completo