Artigo Java Magazine 46 - Refactoring: da Teoria à Prática
Como como utilizar técnicas de refactoring para simplificar a manutenção e melhorar a qualidade e a evolução do seu código.
Melhorando a estrutura do seu código-fonte
Utilizando técnicas de refactoring para simplificar a manutenção e melhorar a qualidade e a evolução do seu código
O refactoring (ou refatoração) é uma atividade comum em processos ágeis como o Extreme Programing, nos quais as mudanças no código são constantes. Essa técnica, no entanto, não é utilizada apenas em softwares desenvolvidos sob esses processos. Seu uso é muito mais abrangente e traz como conseqüência direta um código mais limpo, de manutenção mais fácil e com maior qualidade.
Neste artigo veremos os conceitos de refactoring – quando refatorar uma aplicação e como fazê-lo – e nos apoiaremos nos comandos de refatoração do IDE Eclipse para demonstrar tais tarefas. Embora seja usado um IDE para automatizar alguns passos, o enfoque deste artigo será nas atividades de refatoração em si, de forma independente de ferramentas, bem como nos conceitos fundamentais envolvidos.
O Contexto
Quem nunca se deparou com um código no qual a alteração de um simples método levou à modificação de dezenas de linhas de código? E quando foi necessário manter um método "faz tudo" com 500 linhas? Isso sem falar daqueles métodos com dezenas de parâmetros, códigos duplicados e algoritmos que ninguém consegue entender.
Esses sintomas são denominados "badsmells" (maus cheiros) pelos especialistas em refactoring, e resultam principalmente de um design ruim, ou mesmo da falta de design. Os problemas ficam evidentes quando se deseja incluir uma nova funcionalidade ou alterar o código existente: normalmente é difícil (ou até impossível) mudar o código sem quebrar o funcionamento do programa.
Mas por que alterar?
Suponha que você vem utilizando um componente qualquer, que tem funcionado adequadamente ao longo de vários anos. Durante esse período, o componente foi usado em diversos sistemas e demonstrou funcionamento e performance adequados, o que o tornou bastante confiável.
Agora seu componente será utilizado em um novo sistemas, e para isso algumas alterações deverão ser efetuadas por questões de compatibilidade. O autor do componente não está mais na empresa, e coube a você assumir a nova tarefa.
Só que, se o componente não tiver sido bem projetado, o que parecia uma alteração simples pode se tornar um pesadelo: sistemas com design ruim são difíceis de alterar. Nestes casos, entender o que deve ser mudado não é uma tarefa simples, e são grandes as chances de se introduzir bugs ao longo do processo.
Cria o código é apenas o início. Todos nós sabemos que os sistemas evoluem, e que o que foi acordado com o cliente hoje nem sempre valerá amanhã. Por isso, código bom não é código que "apenas funciona": é código que também é simples de entender, alterar e estender.
As técnicas de refactoring melhoram o design do software e facilitam seu entendimento. Como conseqüência, o tornam mais simples e facilitam a descoberta de bugs.
Entendendo a técnica
Refactoring é uma técnica poderosa, e que precisa ser aplicada com cuidado. O princípio é simples: pequenas alterações são efetuadas de forma incremental no código, enquanto a funcionalidade do sistema permanece inalterada.
A capacidade de refactoring está presente em todos os IDEs modernos, com diferentes graus de sofisticação. Em geral as operações de refactoring automatizadas pelas IDEs são bastante seguras e podem ser efetuadas sem receio.
Dentre os IDEs livres, o Eclipse e o NetBeans destacam-se pela diversidade de comandos, possuindo funcionalidades equivalentes (o plug-in Jackpot aumenta bastante o poder de refactoring do NetBeans, mas deve ser instalado à parte1). Já o IntelliJ IDEA (um produto proprietário) é o IDE com maior capacidade de refactoring existente.
Todas as operações de refactoring disponíveis nas ferramentas de desenvolvimento seguem o catálogo proposto por Martin Fowler (veja as referências ao final do artigo). Porém, como veremos ao longo do texto, nem todas possuem suporte automatizado.
Refatorando
A melhor maneira de fixar os conceitos de refactoring é praticando. A Listagem 1 apresenta a classe CartaoUtil. Nela, o método validar() verifica números de cartões de crédito e imprime uma mensagem indicando se o número do cartão é válido ou não. Os parâmetros para validação são a bandeira do cartão (Visa, MasterCard, American Express ou Diners), além de seu número e data de validade.
package br.com.jm.refactoring;
import java.text.”;
import java.util.*;
public class CartaoUtil {
public static final int VISA = 1;
public static final int MASTERCARD = 2;
public static final int AMEX = 3;
public static final int DINERS = 4;
public static final String CARTAO_OK = “Cartão válido”;
public static final String CARTAO_ERRO = “Cartão inválido”;
public String validar(int bandeira, String numero, String validade) {
boolean validade ok = false;
// ----- VALIDADE -----
Date dataValidade = null;
try {
dataValidade = new SimpledateFormat(“MM/yyyy”).parse(validade);
} catch (ParseException e) {
return CARTAO_ERRO;
}
Calendar calValidade = new GregorianCalendar();
calValidade.setTime(dataValidade);
// apenas mês e ano são utilizados na validação
Calendar calTemp = new GregorianCalendar();
Calendar calHoje = (GregorianCalendar) calValidade.clone();
calHoje.set(Calendar.MONTH, calTemp.get(Calendar.MONTH));
calHoje.set(Calendar.YEAR, calTemp.get(Calendar.YEAR));
validadeOK = calHoje.before(calValidade);
if (!validadeOK) {
return CARTAO_ERRO;
}
else {
// ---- PREFIXO E TAMANHO -----
String formatado = “”;
// remove caracteres não-numéricos
for (int i = 0; i < numero.length(); i++) {
char c = numero.chartAt(i);
if (Character.isDigit(c) {
formatado += c;
}
}
boolean formatoOK = false;
switch (bandeira) {
case VISA: // tamanhos 13 ou 16, prefixo 4.
if (formatado.startsWith(“4”) &&
(formatado.length() == 13 ||
formatado.length() == 16 )) {
formatoOK = true;
} else {
formatoOK = false;
}
break;
case MASTERCARD: // tamanho 16, prefixos 51 a 55
if ((formatado.startsWith(“51”) ||
formatado.startsWith(“52”) ||
formatado.startsWith(“53”) ||
formatado.startsWith(“54”) ||
formatado.startsWith(“55”) &&
formatado.length() == 16) {
formatoOK = true;
} else {
formatoOK = false;
}
break;
case AMEX: // tamanho 15, prefixos 34 e 37.
if ((formatado.startsWith(“34”) ||
formatado.startsWith(“37”) &&
formatado.length() == 15 ) {
formatoOK = true;
} else {
formatoOK = false;
}
break;
case DINERS: // tamanho 14, prefixos 300 305, 36 e38.
if ((formatado.startsWith(“300”) ||
formatado.startsWith(“301”) ||
formatado.startsWith(“302”) ||
formatado.startsWith(“303”) ||
formatado.startsWith(“304”) ||
formatado.startsWith(“305”) ||
formatado.startsWith(“36”) ||
formatado.startsWith(“38”) &&
formatado.length() == 14) {
formatoOK = true;
} else {
formatoOK = false;
}
break;
default:
formatoOK = false;
break;
}
if (!formatoOK) {
return CARTAO_ERRO;
}
else {
// ----- NÚMERO -----
// fórmula de LUHN (http://www.merriampark.com/anatomycc.htm)
int soma = 0;
int digito = 0;
int somafim = 0;
boolean multiplica = false;
for (int 1 = formatado.length() – 1; i >= 0; i--) {
digito = Integer.parseInt(formatado.substring(i,i+1));
if (multiplica) {
somafim = digito * 2;
if (somafim > 9) {
somafim -= 9;
}
} else {
somafim = digito;
}
soma += somafim;
multiplica = !multiplica;
}
int resto = soma % 10;
if (resto == 0) {
return CARTAO_OK;
} else {
return CARTAO_ERRO;
}
}
}
}
}Listagem 1. Classe cartãoUtil original
Analisando o exemplo
Aparentemente o código inicial funciona bem, e valida os quatro tipos de cartão corretamente. Uma análise criteriosa, no entanto, mostra uma série de problemas.
O primeiro ponto que merece destaque é que o código não é verdadeiramente orientado a objetos. Percebe-se que não existe a abstração do principal elemento do negócio: o cartão de crédito. As quatro bandeiras são definidas através de constantes numéricas, o que oferece pouca flexibilidade (se uma nova bandeira tiver que ser adicionada, o código terá que ser alterado).
Além disso, a validade do cartão é definida através de um parâmetro do tipo String, que deve obedecer a uma formatação específica: DD/AAAA. Esse tipo de detalhe torna a aplicação "frágil" e aumenta a possibilidade de bugs.
A instrução switch também contribui para que o código se torne procedural. Se você deseja escrever um código realmente orientado a objetos, de evitar essa construção (como veremos posteriormente, em casos como o mostrado o swicht pode ser facilmente substituído pelo uso de polimorfismo).
Outro problema evidente problema evidente é o tamanho do método. Métodos muito extensos são um indicativo de que fazem mais do que deveriam. A quantidade de condições (ifs e elses) torna complicada sua leitura e aumenta o custo de manutenção. A grande quantidade de returns também dificulta a compreensão do método, pois não é simples entender o seu fluxo.
Por fim, utilizar uma mensagem como retorno do método também não é a melhor opção. Imagine que a mensagem tivesse que ser escrita em HTML, ou então ser internacionalizada para outros idiomas. Neste caso, o código teria que ser modificado, embora sua função principal não tenha relação com a interface com o usuário.
Passo 1:"enxugando" as construções
Antes de aplicar os padrões do catálogo de refactoring, vamos simplificar um pouco o código. Uma análise rápida mostra dois pontos do programa que são suscetíveis à simplificação: laços e condicionais. Utilizaremos expressões regulares para tornar esses trechos mais limpos.
O laço for a seguir remove caracteres inválidos no número do cartão, conservando apenas os dígitos. O número 5501-7615-8613-3399, por exemplo, seria formatado para 55017615861333992:
String formatado ="";
for (int i=0; i<numero.length();i++{
char c=numero.charAt(i);
if(Character.isDigit(c)){
formatado +=c;
}
}O código não é difícil de entender, mas apresenta ao menos dois problemas: a quantidade de linhas necessárias para resolver uma tarefa simples e a concatenação de objetos do tipo String. Em Java, como sabemos, Strings são imutáveis. Isso significa que, a cada concatenação, um novo objeto será criado para armazenar o valor do novo texto. Neste código, por exemplo, a variável formato seria recriada dezesseis vezes. Uma possível solução seria utilizar a classe StringBuffer, mas existe uma forma ainda mais simples de resolver o problema.
Utilizando expressões regulares3, podemos solucionar os dois problemas de uma só vez, obtendo um código simples e de funcionalidade idêntica:
String formatado=numero.replaceAll(“\\D”,"");O segundo ponto passível de alteração são as instruções case. Cada uma dessas instruções valida o formato do cartão de acordo com a bandeira. Os cartões MasterCard, por exemplo, devem iniciar com os números entre 51 e 55 e possuir 16 dígitos:
if((formatado.starsWith("51")||
formatado.startsWith("52")||
formatado.startsWith("53")||
formatado.startsWith("54")||
formatado.startsWith("55")&&
formatado.length()==16){
valido = true;
}else{
valido = false;
}Todo esse código pode ser substituído por uma expressão regular simples:
valido=formatado.matches("^5[1-5]\\d{14}$");Modificando apenas o laço for e as instruções case, já temos uma diminuição significativa na quantidade de linhas e na complexidade do código – veja a Listagem 2. (Nesta e em listagens posteriores, omitimos a parte que não foi alterada depois do refactoring em questão).
Destacamos que neste ponto os casos de teste devem ser re-executados para certificar que o código não foi "quebrado".
Após essa primeira "limpeza", partiremos para operações de refactoring propriamente ditas.
package br.com.jm.refactoring;
import java.text.*;
import java.util.*;
public class CartaoUtil {
// constants da classe
public String validar(int bandeira, String numero, String validade) {
…
if (!validadeOK) {
return CARTAO_ERRO;
}
else {
// ----- PREFIXO E TAMANHO -----
String formatado = numero.replaceAll(“\\D”, “”);
boolean formatoOK = false;
switch (bandeira) {
case VISA; // tamanhos 13 ou 16, prefixo 4.
formatoOK = formatado.matches(“^4(\\d{12}|\\d{15})$”);
break;
case MASTERCARD; // tamanho 16, prefixos 51 A 55
formatoOK = formatado.matches(“^5[1-5]\\d{14}$”);
break;
case AMEX; // tamanho 15, prefixos 34 e 37
formatoOK = formatado.matches(“^3[47]\\d{13}$”);
break;
case DINERS; // tamanho 14, prefixos 300 a 305, 36 e 38.
formatoOK = formatado.matches(“^3[68]\\d{12}|0[0-5]\\d{11})$”);
break;
default;
formatoOK = false;
break;
}
If (!formatoOK) {
return CARTAO_ERRO;
}
else {
// fórmula de LUHN
}
}
}
}Listagem 2. Classe CartaoUtil após o uso de expressões regulares
Passo 2: alterando o retorno
Como analisado anteriormente, o uso de uma mensagem textual como retorno do método traz uma série de inconvenientes para a evolução do sistema. Para resolver o problema, faremos duas alterações no código; trocaremos o tipo de retorno para boolean e criaremos exceções para os possíveis erros de validação.
Neste passo mudaremos o retorno do método. As exceções serão tratadas no Passo 4.
O retorno do método pode ser alterado através do refactoring Change Method Signature. Para efetuar esse refactoring no Eclipse, selecione o método validar() e escolha a opção de menu Refactor>Change Method Signature. A tela da Figura 1 será exibida. Altere o tipo de retorno para boolean e escolha OK; na próxima tela serão exibidos alguns erros de conversão. Ignore-os e aceite as alterações.
O código refatorado apresentará erros nos locais em que as constantes CARTAO_OK e CARTAO_ERRO são referenciadas, pois essas constantes são do tipo String. Para que o código continue compilável, as constantes deverão ser alteradas manualmente para o tipo boolean4:
public static final boolean CARTAO_OK = true;
public static final booelan CARTAO_ERRO = false;Agora que o método retorna um valor booleano indicando o estado do cartão, as constantes CARTAO_OK e CARTAO_ERRO perderam sua utilidade e podem ser removidas. Para remover as constantes de forma segura; usaremos o refactoring Inline constant, que substitui a referência à constante pelo seu valor.
Para realizar a operação basta marcar a constante e selecionar o menu Refactor>Inline. A Figura 2 será exibida. Aceite as opções default e clique em OK. Repita o comando para a outra constante.
Passo 2: criando métodos auxiliares
O método validar() efetua três testes distintos para decidir se o cartão é válido ou não. Primeiro a data de validade é analisada; caso a data esteja correta, o formato do número é checado (prefixo e tamanho). Por fim, se os dois primeiro testes tiverem sucesso, o formato do número é conferido através da fórmula de LUHN (também conhecida como "Módulo 10").
Essa implementação torna o método grande e aumenta a complexidade da manutenção. É recomendável que cada um desses testes seja separado em um método distinto, facilitando o entendimento e permitindo que futuras alterações possam ser feitas de forma pontual. A separação dos métodos será feita através do refactoring Extract method.
Para extrair cada método, basta selecionar o trecho que corresponderá ao método e escolher o comando de menu Refactor>Extract Method. Uma tela semelhante à da Figura 3 será mostrada. Preencha o novo nome do método e aceite as opções default.
Neste exemplo, os três novos métodos foram criados com os nomes isValidadeOK(), isFormatoOK() e isNumeroOK().
A nova classe é exibida na Listagem 3. É importante salientar que nenhum refinamento foi feito ainda sobre os métodos criados. Estes métodos são apenas o resultado do refactotring efetuado pelo Eclipse.
package br.com.jm.refactoring;
import java.text.*;
import java.util.*;
public class CartaoUtil {
// constantes da classe
public boolean validar(int bandeira, String numero, String validade) {
boolean validadeOK = false;
validadeOK = isvalidadeOK(validade);
if (!validadeOK(validade);
return false;
}
else {
// ----- PREFIXO E TAMANHO -----
String formatado = numero.replaceAll(\\D, “”);
boolean formatoOK = false;
formatoOK = isFormatoOK(bandeira, formatado);
if (!formatoOK) {
return false;
}
else {
return isNumeroOK(formatado);
}
}
}
private boolean isValidadeOK(String validade) {
boolean validadeOK;
// ----- VALIDAE ------
Date dataValidade = null;
try {
dataValidade = new SimpleDateFormate(“MM/YYYY”).parse(validade);
} catch (ParseException e) {
return false;
}
Calendar calValidade = new GregorianCalendar();;
calValidade.setTime(datValidade);
// apenas mês e ano são utilizados na validação
Calendar calTemp = new GregorianCalendar();
Calendar calHoje = (GregorianCalendar) calValidade.clone();
callHoje.set(Calendar.MONTH, calTemp.get(Calendar, MONTH));
callHoje.set(Calendar.YEAR, calTemp.get(Calendar, YEAR));
validadeOK = calHoje.before(calValidade);
return validadeOK
}
private boolean isFormatoOK(int bandeira, String formatado) {
bolean formatoOK;
switch (bandeira) {
case VISA; // tamanhos 13 ou 16, prefixo 4.
formatoOK = formatado.matches(“^4(\\d{12}|\\d{15})$”);
break;
case MASTERCARD; // tamanho 16, prefixos 51 A 55
formatoOK = formatado.matches(“^5[1-5]\\d{14}$”);
break;
case AMEX; // tamanho 15, prefixos 34 e 37
formatoOK = formatado.matches(“^3[47]\\d{13}$”);
break;
case DINERS; // tamanho 14, prefixos 300 a 305, 36 e 38.
formatoOK = formatado.matches(“^3[68]\\d{12}|0[0-5]\\d{11})$”);
break;
default;
formatoOK = false;
break;
}
return formatoOk;
}
private boolean isNumeroOK(String formatado) {
// -----NÚMERO-----
// fórmula de LUHN (http://www.merriampark.com/anatomycc.htm)
int soma = 0;
int digito = 0;
int somafim = 0;
boolean multiplica = false;
for (int 1 = formatado.length() – 1; i >= 0; 1--) {
digito = integer.parseInt(formatado.substring(i,i+1));
if (multiplica) {
somafim = digito * 2;
if (somafim > 9) {
somafim -= 9;
}
} else {
somafim = digito;
}
soma += somafim;
multiplica = !multiplica;
}
int resto = soma % 10;
if (resto == 0) {
return true;
} else {
return false;
}
}
}Listagem 3. Classe CartaoUtil após a extração dos métodos
Passo 3: removendo os parâmetros
Analisando novamente o método validar(), percebemos que todos os parâmetros são, na verdade, atributos de um cartão de crédito. Porém, até o momento essa abstração não existe, e o cartão é representado através do conjunto de parâmetros do método: bandeira, número e validade. Uma evolução natural do código deve contemplar essa classe.
Antes de criar a classe Cartao, trabalharemos nos parâmetros do método validar(). Os três parâmetros serão convertidos em atributos da classe CartaoUtil, e o atributo validade será desmembrado em dois atributos inteiros: mes e ano5 (esse tratamento minimiza eventuais erros de formatação). É importante notar que todas essas operações serão feitas manualmente, já que o Eclipse não oferece suporta automatizado para essa etapa.
Em seguida, a classe CartaoUtil será renomeada para Cartao (visto que agora reflete essa abstração) e um construtor será adicionado, com os novos atributos. Como o método de validação agora não possui mais parâmetros e seu retorno é booleano, vamos renomeá-lo para isValido().
Para renomear a classe e o método, é recomendável utilizar o comando de refactoring Rename (Refactor>Rename), que já efetua todas as alterações na classe e em suas dependentes.
Passo 4: adicionado Exceptions
No Passo 1 alteramos o retorno do método para booleano, o que resolveu o problema das mensagens mas trouxe um inconveniente: não é possível saber a causa do erro de validação. Para resolver esse problema usaremos exceções.
As mudanças deste passo seguem o refactoring Replace Error Code with Exception, que não é suportado de forma automática pelo Eclipse. Assim, as exceções deverão ser codificadas manualmente.
Para seguir rigorosamente o refactoring Replace Error Code with Exception como definido no catálogo, ele deveria ser feito no primeiro passo, substituindo as mensagens de erro por exceções. Transferimos o refactoring para esse passo para simplificar o entendimento.
Criaremos três exceções, que refletem os erros da nossa regras de validação: ValidadeIncorretaException, NumeroIncorretoException e FormatoIncorretoException (Listagens 4,5 e 6). As exceções serão introduzidas nos métodos correspondentes para indicar cada uma das situações de erro. É importante salientar que todas as exceções são do tipo RuntimeException, o que significa que seu tratamento não é obrigatório no código chamador.
A substituição de códigos de erro por RuntimeExceptions deve ser feita de forma cuidadosa, pois é fácil introduzir bugs. Uma estratégia é, num primeiro momento, utilizar exceções checadas e verificar pontos do código onde eventualmente será necessário utilizar blocos finally. Após essa etapa, é seguro transformar as exceções em RuntimeExceptions.
As mudanças correspondentes aos Passos 3 e 4 estão refletidas na Listagem 7.
package br.com.jm.refactoring.excecao;
import br.com.jm.refactoring.Cartao;
public class ValidadeIncorretaException extends RuntimeException {
public ValidadeIncorretaException (Cartao cartao) {
super(cartao.getMes() + “/” + cartao.getAno());
}
}Listagem 4. Classe ValidadeIncorretaException
package br.com.jm.refactoring.excecao;
import br.com.jm.refactoring.Cartao;
public class NumeroIncorretoException extends RuntimeException {
public NumeroIncorretoException (Cartao cartao) {
super(cartao.getNumero());
}
}Listagem 5. Classe NumeroIncorretoException
package br.com.jm.refactoring.excecao;
import br.com.jm.refactoring.Cartao;
public class FormatoIncorretoException extends RuntimeException {
public FormatoIncorretoException (Cartao cartao) {
super(cartao.getNumero());
}
}Listagem 6. Classe FormatoIncorretoException
package br.com.jm.refactoring;
import java.text.*;
import java.util.*;
import br.com.jm.refactoring.excecao.*;
public class Cartao {
//... Constantes da classe
private int bandeira;
private String numero;
private int mes;
private int ano;
public Cartao(int bandeira, String numero, int mes, int ano) {
this.bandeira = bandeira;
this.numero = numero;
this.mes = mes;
this.ano = ano;
}
//getters omitidos
public boolean isValido() {
...
}
private boolean isValidadeOK(int mes, int ano) {
...
}
private boolean isFormatoOK(int bandeira, String formatado) {
...
}
private boolean isNumeroOK(String formatado) {
...
}
}Listagem 7. Classe Cartao (antiga CartaoUtil)
Passo 5: switch e classes do modelo
A última mudança no código trata do switch. Como indicado anteriormente, implementar a lógica de validação das bandeiras através desse condicional não é a melhor estratégia; a cada nova bandeira a classe Cartao deverá ser alterada para adição de um novo case. Além disso, misturar validações distintas em um mesmo método pode prejudicar o entendimento do código.
A solução para esse problema consiste em separar cada validação em uma classe específica (sob uma mesma hierarquia), e através de polimorfismo executar a validação apropriada. Ao todo, serão criadas quatro classes, uma para cada bandeira.
A alteração no código de validação será feita através do refactoring Replace Conditional with Polymorphism. Esse refactoring também não possui suporte automatizado no Eclipse, portanto as mudanças deverão ser feitas manualmente.
A refatoração será efetuada aplicando-se o pattern Template Method. Primeiro será criado o método formato(), responsável por retornar o formato utilizado na validação da bandeira. Esse método será abstrato na classe Cartao (que será transformada em abstrata) e implementado em cada uma das bandeiras.
protect abstract String formato();Como o formato será definido através de polimorfismo, o atributo bandeira e as constantes das bandeiras não têm mais valor e serão removidos da classe. Também serão necessárias algumas mudanças no método isFormatoOK() para refletir a nova estratégia:
private boolean isFormatoOK(String formatado){
if(!formatado.matches(formato())){
throw new FormatoIncorretoException(this);
}
else{
return true;
}
}Com a nova implementação, o método isFormatoOK() chama o método formato() sempre que precisa verificar o formato de um cartão. Esse método estará implementado em casa uma das bandeiras e será executado conforme a instância criada. Para cartões MasterCard, por exemplo, o método retorna o seguinte formato:
protected String formato(){
return "^5[1-5]\\d{14}$";
}A nova classe Cartao encontra-se na Listagem 8. As classes para cada uma das bandeiras podem ser vistas nas Listagens de 9 a 12.
package br.com.jm.refactoring;
import java.text.*;
import java.util.*;
import br.com.jm.refactoring.excecao.*;
public abstrat class Cartao {
private String numero;
private int mes;
private int ano;
public Cartao (String numero, int mes, inte ano) {
this.numero = numero;
this.mes = mes;
this.ano = ano;
}
//getters omitidos
public boolean isValido() {
...
}
private boolean isValidadeOK(int mes, int ano) {
...
}
protected abstract String formato();
private boolean if FormatoOK(String formatado) {
if (!formatado.matches(formato())) {
throw new FormatoIncorretoException(this);
}
else {
return true;
}
}
private boolean isNumeroOK(String formatado) {
...
}
}Listagem 8. Classe Cartao após o uso de polimorfismo
package br.com.jm.refactoring;
public class visa extends Cartao {
public Visa(String numero, int mes, int ano) {
super(numero, mes, ano);
}
@Override
protected String formato() {
return “^4(\\d{12}|\\d{15})$”;
}
}Listagem 9. Classe para validação de cartões Visa
package br.com.jm.refactoring;
public class visa extends Cartao {
public Mastercard(String numero, int mes, int ano) {
super(numero, mes, ano);
}
@Override
protected String formato() {
return “^5[1-5]\\d{14}$”;
}
}Listagem 10. Classe para validação de cartões Mastercard
package br.com.jm.refactoring;
public class Amex extends Cartao {
public Amex(String numero, int mes, int ano) {
super(numero, mes, ano);
}
@Override
protected String formato() {
return “^3[47]\\d{13}$”;
}
}Listagem 11. Classe para validação de cartões American Express
package br.com.jm.refactoring;
public class Diners extends Cartao {
public Diners(String numero, int mes, int ano) {
super(numero, mes, ano);
}
@Override
protected String formato() {
return “^3[68]\\d{12}|0[0-5]\\d{11})$”;
}
}Listagem 12. Classe para validação de cartões Diners
Conclusões
Efetuando refactorings progressivos sobre o software, conseguimos torná-lo mais simples e facilitar sua evolução. A criação de bandeiras, por exemplo, tornou-se um processo simples: basta implementar uma nova classe que estenda Cartao e codificar o método formato(). As regras de cada bandeira agora estão descritas em classes específicas, e nenhuma alteração é necessária na classe Cartao.
Obviamente algumas melhorais ainda poderiam ser feitas no código para torná-lo mais robusto como, por exemplo, a alteração do parse no método isValidadeOK(), ou a inclusão de um atributo para representar o titular do cartão. Por questões de espaço, no entanto, não abordaremos essas melhorias aqui.
O refactotring é uma técnica poderosa e de extrema importância. Seu uso ajuda a tornar as aplicações mais simples e extensíveis e até prevenir bugs. A técnica é simples, e possui excelente suporte de IDEs. Seu uso constante, portanto, é altamente recomendável.
_________________________________________
[1] – O Jackpot está em desenvolvimento e é planejado para incorporação à versão 6.0 do NetBeans.
[2]- Os números de cartões utilizados nesse artigo foram criados de acordo com o algoritmo apropriado (fórmula de LUHN), mas, em princípio, não existem.
[3] – O artigo “Uma Mala Direta com JavaMail” na Edição 39 apresentou o essencial sobre expressões regulares dentro de uma aplicação prática. Você pode ver mais detalhes sobre a sintaxe dessas expressões na JavaDoc da classe java.util.regex.Pattern.
[4] – Uma alternativa é utilizar a opção “quick fix” do Eclipse. Selecione a opção Change type of 'CARTAO_ERRO' to 'boolean'. Ainda assim o valor da constante (false) terá que ser alterado manualmente.
Confira outros conteúdos:
Por
André
Em 2008
<Perguntas frequentes>
Nossos casos de sucesso
Eu sabia pouquíssimas coisas de programação antes de começar a estudar com vocês, fui me especializando em várias áreas e ferramentas que tinham na plataforma, e com essa bagagem consegui um estágio logo no início do meu primeiro período na faculdade.
Estudo aqui na Dev desde o meio do ano passado!
Nesse período a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha
empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta é continuar estudando e praticando para ser um
Full-Stack Dev!
Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma é bem intuitiva e muuuuito didática a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!
Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda não tinha visto. A didática é do jeito que qualquer pessoa consegue aprender. Sério, to apaixonado, adorando demais.
Adquiri o curso de vocês e logo percebi que são os melhores do Brasil. É um passo a passo incrível. Só não aprende quem não quer. Foi o melhor investimento da minha vida!
Foi um dos melhores investimentos que já fiz na vida e tenho aprendido bastante com a plataforma. Vocês estão fazendo parte da minha jornada nesse mundo da programação, irei assinar meu contrato como programador graças a plataforma.
Wanderson Oliveira
Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exercícios práticos que não tem como não aprender, estão de parabéns!
Obrigado DevMedia, nunca presenciei uma plataforma de ensino tão presente na vida acadêmica de seus alunos, parabéns!
Eduardo Dorneles
Aprendi React na plataforma da DevMedia há cerca de 1 ano e meio... Hoje estou há 1 ano empregado trabalhando 100% com React!
Adauto Junior
Já fiz alguns cursos na área e nenhum é tão bom quanto o de vocês. Estou aprendendo muito, muito obrigado por existirem. Estão de parabéns... Espero um dia conseguir um emprego na área.