A import�ncia dos Padr�es de Projeto

Por que eu devo ler este artigo:Este artigo apresentar� os padr�es de projeto, com enfoque nos benef�cios que podem ser obtidos atrav�s da correta utilizaç�o dos mesmos.

Somente conhecer e utilizar os princ�pios b�sicos da orientaç�o a objetos ou de uma linguagem de programaç�o, n�o garante o desenvolvimento de softwares flex�veis, reutiliz�veis e de f�cil manutenç�o. Os padr�es de projeto representam soluç�es que tentam suprir tais necessidades.

Guia do artigo:

Princ�pios de Design de Software
Coes�o versus Acoplamento
Programar para Interface e n�o para Implementaç�o
Herança
Padr�o de Projeto
Cat�logo de Padr�es
Padr�es Criacionais
Padr�es Estruturais
Padr�es Comportamentais
Strategy
Conclus�o

Com a finalidade de proporcionar o reuso da experi�ncia adquirida na soluç�o de problemas corriqueiros, o conceito de padr�o de projeto surgiu na construç�o civil e posteriormente foi adotado pela Engenharia de Software. Entretanto, somente se tornou popular no mundo do desenvolvimento de software ap�s o lançamento do livro Design Patterns: Elements of Reusable Object-Oriented Software, escrito por quatro autores, que posteriormente ficaram conhecidos como a �Gangue dos Quatro�.

Quando utilizados de forma correta, os padr�es de projeto colaboram para a obtenç�o de um design flex�vel, mais coeso e menos acoplado. Neste artigo, abordaremos os padr�es de projeto catalogados pela �Gangue dos Quatro�, com enfoque nos benef�cios obtidos atrav�s da utilizaç�o dos mesmos.

Os padr�es de projeto, tamb�m conhecidos pelo termo original em ingl�s design patterns, descrevem soluç�es para problemas recorrentes no desenvolvimento de software, e quando utilizados de forma correta, refletem diretamente no aumento da qualidade do c�digo, tornando-o mais flex�vel, elegante e reus�vel.

A ideia de padr�es de projeto n�o se restringe ao desenvolvimento de software. Ela foi elaborada na d�cada de 70, pelo arquiteto Christopher Alexander, que escreveu o primeiro cat�logo de padr�es de que se tem conhecimento. Neste cat�logo foram descritos padr�es em projetos da construç�o civil.

Somente ap�s o lançamento do livro Design Patterns: Elements of Reusable Object-Oriented Software, em 1995, que os padr�es realmente ganharam popularidade no mundo do desenvolvimento de software. Neste livro foram catalogados e descritos vinte e tr�s padr�es para o desenvolvimento de software orientado a objetos. Seus autores, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, ficaram conhecidos como a �Gangue dos Quatro� (Gang of Four) ou simplesmente GoF. Posteriormente, v�rios outros livros do estilo foram publicados. Tendo, inclusive, a Sun Microsystems, publicado, em 2002, a primeira ediç�o do livro Core J2EE Patterns: Best Practices and Design Strategies, que catalogou vinte e cinco padr�es voltados para o J2EE, utilizando e baseando-se nos padr�es GoF.

Neste contexto, a principal vantagem do uso de padr�es de projeto est� no reuso das soluç�es propostas para determinado problema, o que permite que at� mesmo profissionais menos experientes possam atuar como especialistas. Pois os padr�es, geralmente, s�o frutos da experi�ncia de profissionais experientes que tiveram a oportunidade de aplicar e validar tais soluç�es em projetos reais. Al�m disso, podemos destacar a facilitaç�o da manutenç�o, j� que um padr�o representa uma unidade de conhecimento comum entre os envolvidos.

A utilizaç�o de alguns padr�es, apesar de ser ben�fica na maioria dos casos, torna o c�digo-fonte maior e mais complexo. Isto nos faz refletir sobre a possibilidade de estarmos desnecessariamente aumentando a complexidade do design. Portanto, � necess�rio n�o somente conhecer os padr�es de projeto, mas sim, realmente entend�-los para identificar quando utiliz�-los e usufruir positivamente da experi�ncia herdada.

Neste artigo iremos abordar os padr�es de projeto catalogados pela Gangue dos Quatro, aplicados � linguagem Java. Apesar disso, vale ressaltar que tais padr�es podem ser implementados em qualquer linguagem de programaç�o orientada a objetos.

Deste modo, primeiramente analisaremos alguns princ�pios de design de software, a fim de construir uma base s�lida, para logo ap�s apresentar como um padr�o de projeto pode ser definido, organizado e catalogado, exemplificar alguns padr�es e casos de uso.

Princ�pios de Design de Software

Como vimos at� o momento, os padr�es de projeto s�o soluç�es robustas e flex�veis que tornam a evoluç�o do software uma tarefa menos dolorosa. Em uma an�lise mais profunda, pode-se notar que tais benef�cios s�o frutos de alguns princ�pios da orientaç�o a objetos, que s�o comuns entre os padr�es. Portanto, vamos refletir sobre alguns desses princ�pios, antes de aprofundarmos nosso estudo sobre os padr�es.

Coes�o versus Acoplamento

A coes�o se refere ao escopo do objeto, ou seja, est� diretamente relacionada com as responsabilidades atribu�das ao objeto para que cumpra a sua finalidade. Para obter um design coeso devemos definir claramente o prop�sito do objeto e centralizar nele tudo o que o diz respeito, evitando que os algoritmos se espalhem pelo projeto dificultando a localizaç�o e, consequentemente, a manutenç�o.

O acoplamento est� relacionado com o grau de depend�ncia entre os objetos, ou seja, o conhecimento necess�rio dos atributos e m�todos de uma classe para que a mesma possa ser utilizada por outra e as colaboraç�es possam ocorrer. A flexibilidade � o quesito mais afetado em um design acoplado, pois o mesmo n�o permite que os elementos da composiç�o de objetos sejam facilmente substitu�dos sem que o funcionamento seja prejudicado.

Em um projeto de software, coes�o e acoplamento devem ser grandezas inversas, sendo que o ideal seria projetar com alta coes�o e baixo acoplamento, centralizando as responsabilidades e compondo estruturas flex�veis, de forma a facilitar futuras manutenç�es.

Programar para Interface e n�o para Implementaç�o

Uma interface � basicamente um contrato, onde s�o declaradas as operaç�es que dever�o ser suportadas pela classe que a implementar. Atrav�s das interfaces, na linguagem Java, � poss�vel colocar em pr�tica o conceito de polimorfismo, onde diferentes objetos que implementam uma interface comum, suportam as mesmas operaç�es, mas possivelmente com implementaç�es diferentes. O polimorfismo resulta em maior flexibilidade para o design, pois desacopla os objetos e permite que eles sejam permutados em tempo de execuç�o (dynamic binding).

Observe o cen�rio da classe Cliente, apresentada na Listagem 1, que necessita obter conex�o com apenas um servidor de banco de dados Oracle atrav�s da classe ConexaoOracle, apresentada na Listagem 2.

Listagem 1. C�digo da classe Cliente.

public class Cliente {
    public static void main(String[] args) {
      // obtendo conex�o com servidor Oracle
      ConexaoOracle conexaoOracle = new ConexaoOracle();
     conexaoOracle.conectar();
    }
  }

Listagem 2. C�digo da classe ConexaoOracle.

public class ConexaoOracle {
    public void conectar() {
      System.out.println("Obtendo conex�o no servidor Oracle!");
    }
  }

Apesar de o software funcionar utilizando banco de dados Oracle, alguns potenciais clientes j� possuem outros servidores de bancos de dados. Assim, para atend�-los, o software ter� de ser capaz de se conectar a diferentes serviços de armazenamento de dados. Neste exemplo os benef�cios ser�o m�nimos, mas ser� poss�vel entender o conceito e os benef�cios de se programar voltado para uma interface e n�o para uma implementaç�o concreta. Para isso, conforme apresentado na Listagem 3, criaremos a interface Conexao, que ser� o nosso �contrato�.

Listagem 3. Interface Conexao.

public interface Conexao {
    void conectar();
  }

A partir de agora, para suprir as necessidades da classe Cliente, ser� necess�rio uma inst�ncia de uma classe que implemente a interface Conexao. A flexibilidade adv�m da possibilidade de mudar a implementaç�o da interface, inclusive em tempo de execuç�o, como demonstrado na Listagem 4.

Listagem 4. Classe Cliente obtendo conex�es a diversos servidores de banco de dados.

public class Cliente {
    public static void main(String[] args) {
      Conexao conexao;
   
      // obtendo conex�o com servidor Oracle
      conexao = new ConexaoOracle();
      conexao.conectar();
   
      // obtendo conex�o com servidor MySQL
      conexao = new ConexaoMySQL();
      conexao.conectar();
   
      // obtendo conex�o com servidor Oracle
      conexao = new ConexaoSQLServer();
      conexao.conectar();
    }
  }

Favorecer a Composiç�o sobre a Herança

A utilizaç�o da herança, apesar de trazer algumas facilidades, apresenta diversos problemas de acoplamento e dificulta a customizaç�o devido ao seu comportamento encadeado, pois quando se faz necess�ria alguma atualizaç�o na superclasse, o comportamento alterado � refletido tamb�m para as subclasses.

A herança tamb�m pode ser considerada uma m� pratica, pois caracteriza a violaç�o do principio do encapsulamento, que rege que os atributos dizem respeito somente a sua pr�pria classe e n�o devem ser manipulados pelas demais.

Apesar de seu uso n�o ser recomendado, a herança pode ser utilizada, com bom senso, em casos espec�ficos em que � poss�vel dizer que a subclasse �� UM� tipo da superclasse. Enquanto a composiç�o � empregada quando o objeto, para estender as suas funcionalidades, �TEM UM� outro que o auxilia. A composiç�o estende uma classe atrav�s da delegaç�o do trabalho para outro objeto.

A composiç�o � vantajosa devido a agregar uma estrutura independente ao objeto, que pode ser alterada sem se preocupar com a propagaç�o da alteraç�o, e n�o viola o princ�pio do encapsulamento. Al�m de que, atrav�s da composiç�o, � poss�vel reproduzir quase todos os recursos da herança.

Definindo Padr�o de Projeto

Um padr�o de projeto � uma estrutura recorrente que resolve satisfatoriamente um determinado problema em seu contexto. Portanto, � importante estud�-lo a fim de promover o seu reuso.

Segundo o modelo da Gangue dos Quatro, cada padr�o possui quatro elementos essenciais: nome, problema, soluç�o e consequ�ncias.

O nome � uma maneira de descrever o problema, sua soluç�o e as consequ�ncias em uma ou duas palavras. Um identificador que contribui para o aumento do n�vel de abstraç�o e para a geraç�o de um vocabul�rio comum, facilitando a comunicaç�o;
O problema descreve quando aplicar o padr�o, definindo os problemas que podem ser solucionados e seus contextos;
A soluç�o descreve os elementos que comp�em a modelagem, seus relacionamentos e responsabilidades. Ela n�o descreve uma modelagem ou implementaç�o concreta, mas sim uma soluç�o gen�rica, visto que um padr�o � aplic�vel a diferentes situaç�es e independente de tecnologia;
As consequ�ncias s�o os resultados e riscos assumidos atrav�s da implementaç�o do padr�o, onde � poss�vel avaliar os custos e benef�cios da soluç�o, e decidir quando utiliz�-la.

Organizando o Cat�logo de Padr�es

Os padr�es GoF foram classificados de acordo com dois crit�rios. O primeiro crit�rio, denominado prop�sito, reflete o que o padr�o faz. Os padr�es podem ter prop�sito criacional, estrutural ou comportamental. Os padr�es criacionais abstraem o processo de criaç�o dos objetos. Os estruturais lidam com a composiç�o de classes ou objetos. J� os comportamentais caracterizam as maneiras pelas quais classes ou objetos interagem e distribuem responsabilidades.

O segundo crit�rio, denominado escopo, especifica se o padr�o � aplic�vel principalmente �s classes ou aos objetos. Os padr�es de classe lidam com o relacionamento entre classes e suas subclasses. Enquanto os padr�es de objetos lidam com as relaç�es entre objetos, que podem ser alteradas em tempo de execuç�o e por isso s�o mais din�micos. Veja a Tabela 1.

		Prop�sito
		Criacional	Estrutural	Comportamental
Escopo	Classe	Factory Method	Adapter	Interpreter Template Method
Escopo	Objeto	Abstract Factory Builder Prototype Singleton	Adapter Bridge Composite Decorator Facade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

Tabela 1. Classificaç�o dos padr�es apresentada no cat�logo da Gangue dos Quatro.

Padr�es Criacionais

Os padr�es criacionais, est�o ligados � forma pela qual os objetos de uma determinada classe s�o criados. Tais padr�es tornam o software independente de como os objetos s�o criados e compostos. Devido a isso, proporcionam grande flexibilidade e permitem a configuraç�o do software como produto de objetos que variam em estrutura e funcionalidade.

A seguir, ser� apresentado um exemplo de padr�o criacional.

Singleton

O padr�o Singleton, garante a exist�ncia de apenas uma inst�ncia da classe no ciclo de vida do aplicativo. Pois encapsula a l�gica de instanciaç�o da classe e quando solicitado verifica se j� n�o existe uma instancia v�lida, n�o sendo necess�rio e nem mesmo permitido instanciar novamente.

A inst�ncia � criada e gerenciada pela pr�pria classe, atrav�s de uma referencia est�tica a si mesma. Para isso, o construtor passa a ser privado para garantir que n�o seja poss�vel criar objetos de fora da classe. A criaç�o, por sua vez, passa a ser controlada atrav�s de um m�todo publico e est�tico, que se torna o �nico meio de se obter uma instancia da classe.

Seu uso � recomendado para reduzir a instanciaç�o desnecess�ria de objetos que seriam utilizados e logo descartados pelo Garbage Collector, e tamb�m de objetos considerados �pesados� como, por exemplo, aqueles que realizam interaç�es com o banco de dados.

Para exemplificar, analisaremos na Listagem 5, a classe utilit�ria ResourceBundleUtils, a qual � empregada na internacionalizaç�o de aplicaç�es e provavelmente utilizada em todas as telas da aplicaç�o, sem a real necessidade uma instancia diferente para cada tela. Assim como tamb�m ser� demonstrada na Listagem 6, a obtenç�o da instancia atrav�s da utilizaç�o do padr�o Singleton.

Garbage Collector: Processo utilizado para automaç�o do gerenciamento de mem�ria, que tem como principio b�sico encontrar objetos que n�o ser�o mais acessados e automaticamente desalocar os recursos utilizados por eles.

Internacionalizaç�o: Processo de desenvolvimento e/ou adaptaç�o de um produto, geralmente softwares, para o idioma e cultura de um pa�s.

Listagem 5. C�digo da classe ResourceBundleUtils.

import java.util.ResourceBundle;

   
  public class ResourceBundleUtils {
   
    private static ResourceBundleUtils instance;
    private ResourceBundle bundle;
   
    private ResourceBundleUtils() {
      bundle = ResourceBundle.getBundle("pt_BR");
    }
   
    public static ResourceBundleUtils getInstance() {
      if (instance == null) {
        instance = new ResourceBundleUtils();
      }
      return instance;
    }
   
    public String getMessage(String key) {
      return bundle.getString(key);
    }
  }

Listagem 6. Exemplo de obtenç�o de instancia atrav�s do padr�o Singleton.

public class Contexto {
    public static void main(String[] args) {
      //obtendo inst�ncia de ResourceBundleUtils atrav�s do padr�o Singleton
      ResourceBundleUtils bundle = ResourceBundleUtils.getInstance();
    }
  }

Padr�es Estruturais

Os padr�es estruturais definem maneiras de se compor objetos para formar estruturas maiores e mais complexas. Ao inv�s de compor interfaces ou implementaç�es, os padr�es estruturais descrevem formas de se compor objetos para realizar novas funcionalidades. A flexibilidade obtida � fruto da possibilidade de alterar a composiç�o em tempo de execuç�o.

A seguir, ser� apresentado um exemplo de padr�o estrutural.

Facade

O padr�o Facade representa uma soluç�o elegante na comunicaç�o entre subsistemas, pois centraliza em um �nico ponto toda a comunicaç�o que ocorre entre eles, reduzindo o acoplamento e facilitando a manutenç�o.

A estruturaç�o de um sistema em subsistemas ajuda a reduzir a complexidade. Nesse contexto, os esforços se intensificam a fim de minimizar a comunicaç�o e as depend�ncias entre os subsistemas. O que vem ao encontro do objetivo do padr�o Facade, visto que o mesmo define uma interface �nica e de alto n�vel que torna mais f�cil a utilizaç�o de um subsistema.

Para exemplificar, analisaremos um cen�rio onde uma classe Cliente, apresentada na Listagem 7, necessita executar operaç�es de outras classes que fazem parte de um subsistema. Observe o diagrama de classes apresentado na Figura 1.

Figura 1. Diagrama de Classes sem utilizaç�o do padr�o Facade.

Listagem 7. C�digo da classe Cliente.

public class Cliente {

ClasseA classeA = new ClasseA();
   
   ClasseB classeB = new ClasseB();
   
   ClasseC classeC = new ClasseC();
  }

Como foi poss�vel observar, o Cliente acessa diretamente as classes internas ao subsistema. Note que tal relacionamento acopla o design, pois vincula o Cliente diretamente �s classes que se relaciona. Podemos diminuir o acoplamento atrav�s da inclus�o de um objeto intermedi�rio que se comportar� como uma fachada e ser� respons�vel pela comunicaç�o externa com o subsistema. Observe as modificaç�es no diagrama de classes apresentado na Figura 2.

Figura 2. Diagrama de Classes com utilizaç�o do padr�o Facade.

Listagem 8. C�digo da classe Facade.

public class Facade {
   
   public ClasseA getClasseA() {
    return new ClasseA();
   }
   
   public ClasseB getClasseB() {
    return new ClasseB();
   }
   
   public ClasseC getClasseC() {
    return new ClasseC();
   }
  }

Neste simples exemplo, nossa fachada, apresentada na Listagem 8, ser� respons�vel apenas pela instanciaç�o das classes integrantes do subsistema. Mas sua utilizaç�o pode ser estendida para encapsular complexidades desnecess�rias para o Cliente como, por exemplo, convers�es de tipo de dados e c�lculos. Observe agora, na Listagem 9, como a classe Cliente passar� a acessar as classes do subsistema utilizando o padr�o Facade, evitando o acesso direto e tornando o design menos acoplado.

Listagem 9. C�digo da classe Cliente.

public class Cliente {
   public static void main(String[] args) {
   
    // instanciando a fachada
    Facade facade = new Facade();
   
    ClasseA classeA = facade.getClasseA();
   
    ClasseB classeB = facade.getClasseB();
   
    ClasseC classeC = facade.getClasseC();
   
   }
  }

Padr�es Comportamentais

Os padr�es comportamentais preocupam-se com os algoritmos e a atribuiç�o de responsabilidades entre os objetos. Esses padr�es s�o caracterizados pelo complexo controle de fluxo, dif�cil de acompanhar em tempo de execuç�o, mas permitem que o desenvolvedor se concentre apenas em como os objetos est�o interligados.

A seguir, ser�o apresentados alguns exemplos de padr�es comportamentais.

Iterator

O padr�o Iterator prov� uma forma de sequencialmente acessar objetos de uma coleç�o, sem expor sua implementaç�o ou estrutura interna. Para isso, prop�e a centralizaç�o de todas as regras de navegaç�o da coleç�o em uma classe, de forma que tais regras possam variar sem que seja necess�rio expor os detalhes de nossas coleç�es.

A linguagem Java possui suporte nativo ao padr�o Iterator atrav�s da interface java.util.Iterator, e o utiliza amplamente para manipular coleç�es no Java Collections Framework.

Java Collections Framework: Framework presente desde a vers�o 1.2 do JDK, que abrange um conjunto de classes e interfaces que implementam estruturas de dados de coleç�es comumente reutiliz�veis.

Para demonstrar a efic�cia deste padr�o, vejamos um exemplo em que o objetivo � listar os itens de duas coleç�es compostas por elementos do tipo Pessoa (vide Listagem 10). Para enfatizar que n�o h� necessidade de expor nossas coleç�es ao usu�rio, utilizaremos duas estruturas de dados distintas: um ArrayList na Listagem 11, e um vetor na Listagem 12. Contudo, inicialmente ser� apresentada uma vers�o sem a implementaç�o do padr�o Iterator, para que seja poss�vel adicion�-lo e assim observar as diferenças.

Listagem 10. C�digo da classe Pessoa.

public class Pessoa {
   private Integer codigo;
   private String nome;
   
   public Pessoa(Integer codigo, String nome) {
    this.codigo = codigo;
    this.nome = nome;
   }
   
   public Integer getCodigo() {
    return codigo;
   }
   
   public void setCodigo(Integer codigo) {
    this.codigo = codigo;
   }
   
   public String getNome() {
    return nome;
   }
   
   public void setNome(String nome) {
    this.nome = nome;
   }
  }

Listagem 11. C�digo da classe Homens.

public class Homens {
   private ArrayList<Pessoa> homens;
   
   public Homens() {
    homens = new ArrayList<Pessoa>();
   
    adicionarPessoa(1, "Mario");
    adicionarPessoa(2, "Jo�o");
    adicionarPessoa(3, "Jos�");
    adicionarPessoa(4, "Fernando");
    adicionarPessoa(5, "Carlos");
   }
   
   public void adicionarPessoa(Integer codigo, String nome) {
    Pessoa homem = new Pessoa(codigo, nome);
    homens.add(homem);
   }
   
   public ArrayList<Pessoa> getPessoas() {
    return homens;
   }
  }

Listagem 12. C�digo da classe Mulheres.

public class Mulheres {
   private Pessoa[] mulheres;
   
   public Mulheres() {
    mulheres = new Pessoa[5];
    
    adicionarPessoa(0, 1, "Maria");
    adicionarPessoa(1, 2, "Joana");
    adicionarPessoa(2, 3, "Camila");
    adicionarPessoa(3, 4, "Fernanda");
    adicionarPessoa(4, 5, "Carla");
   }
   
   public void adicionarPessoa(Integer indice, Integer codigo, String nome) {
    Pessoa mulher = new Pessoa(codigo, nome);
    mulheres[indice] = mulher;
   }
   
   public Pessoa[] getPessoas() {
    return mulheres;
   }
  }

Listagem 13. C�digo da classe RelatorioDePessoas.

public class RelatorioDePessoas {
    public static void main(String[] args) {
   
      /**
       * Obtendo ArrayList de Homens
       */
      Homens arrayListHomens = new Homens();
      ArrayList<Pessoa> homens = arrayListHomens.getPessoas();
   
      /**
       * Listando pessoas do ArrayList
       */
      for (int i = 0; i < homens.size(); i++) {
        Pessoa homem = homens.get(i);
        System.out.println(homem.getCodigo() + " - " + homem.getNome());
      }
   
      /**
       * Obtendo vetor de Mulheres
       */
      Mulheres vetorMulheres = new Mulheres();
      Pessoa[] mulheres = vetorMulheres.getPessoas();
   
      /**
       * Listando pessoas do vetor
       */
      for (int i = 0; i < mulheres.length; i++) {
        Pessoa mulher = mulheres[i];
        System.out.println(mulher.getCodigo() + " - " + mulher.getNome());
      }
   
    }
  }

Como podemos observar na Listagem 13, al�m de expor nossas coleç�es e suas estruturas internas, foi necess�ria a repetiç�o de dois trechos de c�digo praticamente iguais.

Vejamos agora como a implementaç�o do padr�o ir� tornar o nosso c�digo mais simples e elegante. Para isso, criaremos a nossa pr�pria interface Iterator (vide Listagem 14), que ir� conter a assinatura de apenas dois m�todos para controlar o acesso aos itens das coleç�es. Nas Listagens 15 e 16, s�o apresentadas as implementaç�es desta interface para encapsular as regras de navegaç�o das distintas estruturas de dados.

Listagem 14. Interface Iterator.

public interface Iterator {
   /**
    * M�todo que ir� verificar a exist�ncia de um pr�ximo item na coleç�o
    */
   boolean hasNext();
   
   /**
    * M�todo que ir� retornar um item da coleç�o
    */
   Object next();
  }

Listagem 15. C�digo da classe HomensIterator.

public class HomensIterator implements Iterator {
   
   private ArrayList<Pessoa> homens;
   private int indice = 0;
   
   public HomensIterator(ArrayList<Pessoa> homens) {
    this.homens = homens;
   }
   
   /**
    * M�todo que verifica a exist�ncia de um pr�ximo item no ArrayList
    */
   @Override
   public boolean hasNext() {
    return (homens.size() > indice);
   }
   
   /**
    * M�todo que retorna o item localizado em determinada posiç�o do ArrayList
    */
   @Override
   public Object next() {
    return homens.get(indice++);
   }
  }

Listagem 16. C�digo da classe MulheresIterator.

public class MulheresIterator implements Iterator {
   
    private Pessoa[] mulheres;
    private int indice = 0;
   
    public MulheresIterator(Pessoa[] mulheres) {
      this.mulheres = mulheres;
    }
   
    /**
     * M�todo que verifica a exist�ncia de um pr�ximo item no vetor
     */
    @Override
    public boolean hasNext() {
      return (mulheres.length > indice);
    }
   
    /**
     * M�todo que retorna o item localizado em determinada posiç�o do vetor
     */
    @Override
    public Object next() {
      return mulheres[indice++];
    }
   
  }

Agora que j� possu�mos uma implementaç�o da interface Iterator para cada estrutura de dados utilizada, ser� necess�rio desenvolvermos um meio para acess�-las a fim de manipular nossas coleç�es. Deste modo, para tornar poss�vel o acesso � implementaç�o de Iterator correspondente, acrescentaremos em nossas coleç�es (Listagens 11 e 12) o m�todo getIterator(), que ser� respons�vel por criar e nos retornar os objetos de interaç�o relacionados � coleç�o, conforme demonstrado nas Listagens 17 e 18.

Listagem 17. M�todo acrescentado na classe Homens.

public Iterator getIterator() {
    return new HomensIterator(homens);
   }

Listagem 18. M�todo acrescentado na classe Mulheres.

public Iterator getIterator() {
    return new MulheresIterator(mulheres);
   }

Listagem 19. Classe RelatorioDePessoas utilizando o padr�o Iterator.

public class RelatorioDePessoas {
   
   public void imprimirPessoas(Iterator iterator) {
    while (iterator.hasNext()) {
     Pessoa pessoa = (Pessoa) iterator.next();
     System.out.println(pessoa.getCodigo() + " - " + pessoa.getNome());
    }
   }
   
   public static void main(String[] args) {
    RelatorioDePessoas relatorio = new RelatorioDePessoas();
    relatorio.imprimirPessoas(new Homens().getIterator());
    relatorio.imprimirPessoas(new Mulheres().getIterator());
   }
  }

Note que as duas implementaç�es (Listagens 13 e 19) apresentadas exibem resultados exatamente iguais. Por�m, na Listagem 19, evitamos a repetiç�o desnecess�ria de c�digo e encapsulamos as nossas coleç�es com a implementaç�o do padr�o Iterator. A partir de agora, quem utilizar nossas coleç�es apenas ter� conhecimento de que elas s�o compostas atrav�s da classe Pessoa.

Strategy

O padr�o Strategy define uma maneira de encapsular uma fam�lia de algoritmos, tamb�m conhecidos por estrat�gias, e os torna intercambi�veis. Isto permite que o algoritmo varie independentemente dos Clientes que o utilizam.

Para exemplificar, implementaremos uma Calculadora e suas quatro operaç�es b�sicas: adiç�o, subtraç�o, multiplicaç�o e divis�o. Para tal, começaremos utilizando o princ�pio de programar para interface, criando, na Listagem 20, a interface Operacao. O uso desta interface ir� nos proporcionar a possibilidade de alternar dinamicamente entre as estrat�gias atrav�s do polimorfismo. Depois de definida a interface, � preciso identificar o que tende a variar e separar do que � est�tico, ou seja, definir as estrat�gias e faz�-las implementar a interface que criamos, sendo que cada estrat�gia deve ser implementada em uma classe separada. Desta maneira, as estrat�gias poder�o ser facilmente permutadas. Em nosso exemplo, as estrat�gias ser�o as operaç�es da Calculadora. Como � poss�vel observar nas Listagens 21, 22, 23 e 24, essas estrat�gias definem os algoritmos das operaç�es suportadas. Agora observe como elas ser�o permutadas dinamicamente atrav�s da classe DeterminaOperacao (vide Listagem 25) e a utilizaç�o das mesmas na classe Calculadora, atrav�s do c�digo apresentado na Listagem 26.

Listagem 20. Interface Operacao.

public interface Operacao {
   int executar(int valor1, int valor2);
  }

Listagem 21. C�digo da classe Adiç�o.

public class Adicao implements Operacao {
   
    @Override
    public int executar(int valor1, int valor2) {
     return valor1 + valor2;
    }
   
   }

Listagem 22. C�digo da classe Subtracao.

public class Subtracao implements Operacao {
   
    @Override
    public int executar(int valor1, int valor2) {
     return valor1 - valor2;
    }
   
   }

Listagem 23. C�digo da classe Multiplicacao.

   public class Multiplicacao implements Operacao {
   
    @Override
    public int executar(int valor1, int valor2) {
     return valor1 * valor2;
    }
   
   }

Listagem 24. C�digo da classe Divisao.

public class Divisao implements Operacao {
   
    @Override
    public int executar(int valor1, int valor2) {
     return valor1 / valor2;
    }
   
   }

Listagem 25. C�digo da classe DeterminaOperacao.

public class DeterminaOperacao {
   
   private Operacao operacao;
   
   public DeterminaOperacao(Operacao estrategia) {
    this.operacao = estrategia;
   }
   
   int executar(int valor1, int valor2) {
    return operacao.executar(valor1, valor2);
   }
   
   void trocaAlgoritmo(Operacao novaEstrategia) {
    this.operacao = novaEstrategia;
   }
  }

Listagem 26. C�digo da classe Calculadora.

public class Calculadora {
   
   public DeterminaOperacao determinaOperacao = new DeterminaOperacao(new Adicao());
   
   public void main(String[] args) {
    System.out.println("Efetuando Adiç�o (2+3)");
    System.out.println("2 + 3 = " + determinaOperacao.executar(2, 3));
   
    System.out.println("Efetuando Subtraç�o (3-2)");
    determinaOperacao.trocaAlgoritmo(new Subtracao());
    System.out.println("3 - 2 = " + determinaOperacao.executar(3, 2));
   
    System.out.println("Efetuando Multiplicaç�o (3*2)");
    determinaOperacao.trocaAlgoritmo(new Multiplicacao());
    System.out.println("3 * 2 = " + determinaOperacao.executar(3, 2));
   
    System.out.println("Efetuando Divis�o (3/3)");
    determinaOperacao.trocaAlgoritmo(new Divisao());
    System.out.println("3 / 3 = " + determinaOperacao.executar(3, 3));
   }
  }

Conclus�o

Podemos fazer uma analogia entre os padr�es de projeto e o jogo de xadrez, onde primeiro aprende-se as regras do jogo para depois estudar os movimentos dos grandes jogadores. O mesmo acontece no desenvolvimento de software, onde primeiramente aprendemos os conceitos b�sicos para depois refinarmos nosso conhecimento atrav�s dos bons exemplos.

Os padr�es de projeto n�o se resumem aos padr�es catalogados pela Gangue dos Quatro, por�m foram eles que abriram caminho para que os padr�es se tornassem populares no desenvolvimento de software.

Mais importante do que saber implementar um padr�o, � realmente entender como e qual problema determinado padr�o resolve. A principal causa de insucesso na aplicaç�o dos padr�es � o desconhecimento do seu real prop�sito. Por isso, os padr�es de projeto devem ser utilizados somente quando houver um problema que justifique o seu uso.

Refer�ncias

Design Patterns: Elements of Reusable Object-Oriented Software, GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES J., Addison-Wesley, 1995
Cat�logo de padr�es da Gangue dos Quatro.

Padr�es de Projeto: Soluç�es Reutiliz�veis de Software Orientado a Objetos, GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES J., Bookman, 2000
Traduç�o em l�ngua portuguesa do cat�logo de padr�es da Gangue dos Quatro.

Core J2EE Patterns: Best Practices and Design Strategies, DEEPAK, A.; CRUPI, J.; MALKS, D., 2� Ed., Person, 2003
Cat�logo de padr�es J2EE.

Core J2EE Patterns: As Melhores Pr�ticas e Estrat�gias de Design, DEEPAK, A.; CRUPI, J.; MALKS, D., 2� Ed., Campus, 2004
Traduç�o em l�ngua portuguesa do cat�logo de padr�es J2EE.

Head First � Design Patterns, FREEMAN, Erich; FREEMAN, Elisabeth, O�Reilly Media, 2004
Livro bastante did�tico, da s�rie �Use a Cabeça!�, sobre padr�es de projeto.

Use a Cabeça! - Padr�es de Projeto, FREEMAN, Erich; FREEMAN, Elisabeth, Alta Books, 2007
Traduç�o em l�ngua portuguesa do livro bastante did�tico, da s�rie �Use a Cabeça!�, sobre padr�es de projeto.

Confira tamb�m

Cursos de Java

Cursos

Linguagem Java

Curso

JPQL: Escrevendo consultas na JPA