Uso de Polimorfismo em Java

Introduç�o

Polimorfismo significa "muitas formas", � o termo definido em linguagens orientadas a objeto, como por exemplo Java, C# e C++, que permite ao desenvolvedor usar o mesmo elemento de formas diferentes. Polimorfismo denota uma situaç�o na qual um objeto pode se comportar de maneiras diferentes ao receber uma mensagem. No Polimorfismo temos dois tipos:

Polimorfismo Est�tico ou Sobrecarga
Polimorfismo Din�mico ou Sobreposiç�o

O Polimorfismo Est�tico se d� quando temos a mesma operaç�o implementada v�rias vezes na mesma classe. A escolha de qual operaç�o ser� chamada depende da assinatura dos m�todos sobrecarregados.

O Polimorfismo Din�mico acontece na herança, quando a subclasse sobrep�e o m�todo original. Agora o m�todo escolhido se d� em tempo de execuç�o e n�o mais em tempo de compilaç�o. A escolha de qual m�todo ser� chamado depende do tipo do objeto que recebe a mensagem.

Nos pr�ximos t�picos veremos um pouco mais sobre os dois tipos de polimorfismo discutidos acima e exemplos de como o Polimorfismo � implementado e utilizado na pr�tica em diferentes contextos.

Sobrescrita de M�todos e Sobrecarga

A Sobrescrita de M�todos pode ser classificada como polimorfismo de inclus�o. Quando um m�todo sobrescreve um m�todo herdado de uma classe, temos uma sobrescrita de m�todo. Este m�todo de sobrescrita tem que ser id�ntico ao m�todo da classe herdada, ou seja, eles precisam ter o mesmo nome, valor de retorno e argumentos. Portanto, temos que uma classe filha fornece apenas uma nova implementaç�o para o m�todo herdado e n�o um novo m�todo. Por exemplo, temos uma superclasse Forma e as suas subclasses Triangulo e Circulo. Digamos que a superclasse Forma tem um m�todo chamado calculaArea(). Cada uma das subclasses Triangulo e Circulo definir� o seu pr�prio m�todo calculaArea(). Dependendo do tipo de objeto que for criado teremos a execuç�o do m�todo dessa subclasse.

Se a classe filha fornecer um m�todo de cabeçalho ou assinatura parecida com a do m�todo herdado (difere ou no n�mero ou no tipo dos argumentos) ent�o n�o se trata mais de redefiniç�o, trata-se de uma sobrecarga, pois criou-se um novo m�todo. Uma chamada ao m�todo herdado n�o mais ser� interceptada por esse novo m�todo de mesmo nome. O m�todo tem o mesmo nome, mas � ligeiramente diferente na sua assinatura (o corpo ou bloco de c�digo n�o importa), o que j� implica que n�o proporciona o mesmo comportamento do m�todo da superclasse. Por exemplo, se temos um m�todo soma que aceita um inteiro como par�metro e um outro m�todo soma que recebe dois par�metros inteiros. O m�todo que ser� chamado depende dos argumentos sendo passados na chamada deste m�todo, portanto, se chamarmos soma(1,3) o segundo m�todo ser� chamado.

O tipo de polimorfismo de Sobrecarga permite a exist�ncia de v�rios m�todos de mesmo nome, por�m com assinaturas levemente diferentes, ou seja, variando no n�mero e tipo de argumentos. Ficaria a cargo do compilador escolher de acordo com as listas de argumentos os procedimentos ou m�todos a serem executados.

Sobrecarga de M�todos � comumente usada nos construtores de uma classe Java.

Utilizando Polimorfismo em Padr�es de Projetos

Boa parte dos padr�es de projeto de software baseia-se no uso de polimorfismo, por exemplo: Abstract Factory, Composite, Observer, Strategy, Template Method, etc.

A partir de agora ser� visto como funciona o Abstract Factory, um padr�o de projeto muito utilizado que faz uso do polimorfismo.

Padr�es de Projeto representam soluç�es comprovadas para problemas recorrentes em desenvolvimento de software. A ideia original surgiu em 1979, na Arquitetura e Engenharia Civil com Christopher Alexander, arquiteto, que queria melhorar o processo de projeto de edif�cios e �reas urbanas. No entanto, na Engenharia de Software, quatro autores se basearam em Christopher Alexander para criar Padr�es de Projeto de software. Em 1994 os quatro autores, tamb�m chamados de Gang of Four, descreveram 23 padr�es em seu livro "Padr�es de Projeto: Soluç�es Reutiliz�veis de Software Orientado a Objetos". O livro j� vendeu mais de 500 mil c�pias e tem praticamente uma atualizaç�o por ano.

Conforme os autores, Erich Gamma, et. al, um padr�o de projeto � definido como: �Descriç�o de uma soluç�o para resolver um problema gen�rico de projeto em um contexto espec�fico. [...] Um padr�o de projeto d� nome, abstrai e identifica os aspectos-chave de uma estrutura de projeto comum para torn�-la reutiliz�vel�.

Portanto, os padr�es de projetos s�o especialmente bons para descrever como e por que resolver problemas n�o funcionais facilitando o reuso de soluç�es arquiteturais que j� deram certo no passado.

O Abstract Factory proporciona uma interface para criar fam�lias de objetos relacionados ou dependentes sem especificar suas classes concretas.

Figura 1: Exemplo de implementaç�o do Abstract Factory

Abaixo segue um exemplo de implementaç�o do Abstract Factory.

Listagem 1: Implementaç�o da f�brica abstrata e das f�bricas concretas


        interface GUIFactory
        public Menu createMenu();
        }

        class WinFactory implements GUIFactory {

        public Menu createMenu() {
        return new WinMenu();
        }
        }

        class LinuxFactory implements GUIFactory {
        public Menu createMenu() {
        return new LinuxMenu();
        }
        }

Na listagem 1 tem-se a f�brica abstrata �GUIFactory� que � implementada pelas f�bricas concretas WinFactory e LinuxFactory que v�o criar a mesma coisa, ou seja, um menu, no entanto cada sistema tem seu tipo de menu com seu pr�prio tamanho, tipo, design, etc.

Abaixo tem-se a implementaç�o dos menus para cada sistema.

Listagem 2: Implementaç�o do produto abstrato e dos produtos concretos


        interface Menu {
        public void paint();
        }

        class WinMenu implements Menu {
        public void paint() {
        System.out.println("Eu sou um WinMenu");
        }
        }

        class LinuxMenu implements Menu {
        public void paint() {
        System.out.println("Eu sou um LinuxMenu");
        }
        }

A interface Menu cria o produto abstrato que deve ser implementado pelos produtos concretos WinMenu e LinuxMenu. Podemos notar que temos aqui as classes WinMenu e LinuxMenu com os m�todos paint() que sobrescrevem o m�todo paint() da interface Menu.

No c�digo abaixo temos a execuç�o do padr�o de projeto implementado acima.

Listagem 3: Teste de execuç�o do padr�o


        class Aplicacao {
        public Aplicacao(GUIFactory factory) {
        Menu menu = factory.createMenu();
        menu.paint();
        }
        }

        class Principal {
        public static void main(String args[]) {
        chamar Application();
        //De preferencia leia de algum lugar e coloque a opç�o na vari�vel
        int tipoDeMenu = 0;
        if (tipoDeMenu == 0)
        new Aplicacao(new WinFactory());
        else
        new Aplicacao(new LinuxFactory());
        }
        }

Acima podemos notar que dependendo do par�metro que for passado para a classe Aplicacao podemos ter um retorno diferente, por�m a chamada ser� sempre a mesma (paint).

Aqui temos um exemplo do polimorfismo ajudando na implementaç�o do Padr�o de Projeto Abstract Factory.

Utilizando Polimorfismo em Refatoraç�es

Refatoraç�o � uma (pequena) modificaç�o no sistema que n�o altera o seu comportamento funcional, mas que torna o c�digo mais f�cil de ser entendido e menos custoso de ser alterado. A refatoraç�o visa sempre dar uma maior simplicidade, flexibilidade e clareza para o c�digo.

Alguns exemplos de refatoraç�o s�o: Alterar nomes de vari�veis, m�todos e objetos para melhorar legibilidade do c�digo, mudar par�metros de m�todos para que fiquem mais claros, eliminar duplicaç�o de c�digo, etc.

Um cat�logo com mais de 72 refatoraç�es pode ser encontrado no livro de Martin Fowler, "Refatoraç�o: Aperfeiçoando o Projeto de C�digo Existente".

O polimorfismo tamb�m � usado em uma s�rie de refatoraç�es, como na refatoraç�o �Substituir Comando Condicional por Polimorfismo� que ser� mais detalhada abaixo.

A refatoraç�o �Substituir Comando Condicional por Polimorfismo� move cada ramificaç�o de um comando condicional para um m�todo de sobrescrita em uma subclasse.

Essa refatoraç�o deixa bastante claro um dos grandes objetivos do Polimorfismo que � evitar escrever um comando condicional expl�cito quando temos objetos cujo comportamento varia de acordo com os seus tipos. O grande ganho dessa refatoraç�o � quando temos um grande n�mero dessas condicionais que aparecem em muitos lugares do programa. Se quisermos adicionar um novo tipo, temos que encontrar e atualizar todos os comandos condicionais. Com subclasses precisamos apenas criar uma nova subclasse, isso reduz consideravelmente as depend�ncias no sistema e torna-o muito mais f�cil de atualiz�-lo.

No exemplo abaixo tem-se uma condicional.

Listagem 4: Exemplo utilizando condicional para definir o comportamento


        class TipoEmpregado {

        public int quantiaAPagar() {
        switch(lerTipo()) {
        case TipoDeEmpregado.ENGENHEIRO:
        return _salarioMensal;
        case TipoDeEmpregado.VENDEDOR:
        return _salarioMensal + _comissao;
        case TipoDeEmpregado.GERENTE:
        return _salarioMensal + _bonus;
        default:
        throw new RuntimeException("tipo incorreto de empregado");
        }
        }
        }

Todas essas condicionais, ap�s aplicar a refatoraç�o �Substituir Comando Condicional por Polimorfismo�, vira a implementaç�o abaixo:

Listagem 5: C�digo condicional ap�s aplicar a refatoraç�o


        //Essa classe que vai chamar o TipoDeEmpregado dependendo do tipo passado
        class Empregado {
        int quantiaAPagar() {
        return _tipo.quantiaAPagar(this);
        }
        }

        class TipoDeEmpregado {

        abstract int quantiaAPagar(Empregado emp);
        }

        class Engenheiro extends TipoDeEmpregado {
        int quantiaAPagar(Empregado emp) {
        return emp.lerSalarioMensal();
        }
        }

        class Vendedor extends TipoDeEmpregado {
        int quantiaAPagar(Empregado emp) {
        return emp.lerSalarioMensal() + emp.lerComissao();
        }
        }

        class Gerente extends TipoDeEmpregado {
        int quantiaAPagar(Empregado emp) {
        return emp.lerSalarioMensal() + emp.lerBonus();
        }
        }

A classe Empregado vai delegar para uma classe mais espec�fica o trabalho a ser feito. As classes espec�ficas Engenheiro, Vendedor e Gerente recebem o que antes era feito num comando condicional. Todas as classes mais espec�ficas sobrescrevem a superclasse TipoDeEmpregado.

A ess�ncia do polimorfismo � que, em vez de perguntar a um objeto qual � o seu tipo e ent�o chamar algum comportamento baseado nessa resposta, voc� simplesmente chama o comportamento. O objeto, dependendo do seu tipo, faz a coisa certa.

Conclus�o

Podemos notar a import�ncia do Polimorfismo para a reduç�o de c�digo, simplicidade, flexibilidade, etc. O polimorfismo � utilizado em diversas refatoraç�es e muitos Padr�es de Projetos, portanto entend�-lo � fundamental para qualquer desenvolvedor.

Bibliografia

O que � Polimorfismo?
Fowler, M. Refatoraç�o: Aperfeiçoando o Projeto de C�digo Existente. Bookman, 2004.