Categoria: Java

Olá amigos, colegas e leitores!.

Hoje vou falar um pouquinho sobre o tratamento de exceções em Java. Apresentarei o porque usar, sua estrutura e o que é uma exceção. É comum para os iniciantes nos estudos com Java, ao chegar no assunto “Tratamento de Exceções” não conseguir visualizar a utilidade desse recurso e confundir os resultados com as instruções condicionais.

Para não ficar um artigo muito grande e cansativo, teremos um outro para complementar o que foi discutido aqui, porém de modo prático.

Lets go…

Mas a pergunta é: Por que usar tratamento de exceções?

Usar tratamento de exceções permite detectar erros e manipular esses erros, ou seja, tratá-los.

Instruções condicionais & Tratamento de exceções.

A grande diferença, é que instruções não servem para tratar erros e sim para testar condições se X não for verdadeiro. Assim: ao contrário das exceções que tem como objetivo detectar áreas onde possíveis erros possam acontecer e tratá-lo. Lembre o fato de um programador colocar dentro de uma instrução if…else que, se o usuário não digitar os valores válidos, informa que está errado. Isso não quer dizer que aconteceu um erro e ele foi tratado, apenas que, a condição esperada não aconteceu.

Agora veremos abaixo a estrutura de como tratar um erro ou exceção:

try – é usada para indicar um bloco de código que possa ocorrer uma exceção.

catch – serve para manipular as exceções, ou seja, tratar o erro

finally – sempre será executado depois do bloco try/catch. O importante é saber que esse bloco sempre será executado (exceto nos casos de encerramento da jvm System.exit()).

Veja abaixo as combinações válidas e inválidas para o uso do try{}, cacth{} e finally{} (isso é questão de certificação).

Combinações válidas:

try{}	catch{}
try{}	finally{}
try{}	catch{}	finally{}

Inválidas não Compila:

try{}	—	—
catch{}	finally{}	—
try{}	finally{}	catch{}

O que é uma Exceção?

É uma ocorrência que altera o fluxo do programa. As exceções podem ocorrer por falhas de hardware, exaustão de recursos e erros.

1. As palavras try e catch servem para informar a JVM o que fazer quando ocorrer uma exceção.

2. Os blocos catch devem aparecer após o try (isso é um requisito); entre os blocos não podem possuir nenhuma instrução.

3. Quando uma exceção é identificada no try{} o restante do código não é executado e não há um retorno para o termino do código.

Exceções verificadas e não verificadas

– Toda exceção verificada deriva da class Exception.

– As não verificadas ou não-checadas, deriva da class RuntimeException.

Throwable – é o pai de todas as exceções.

Error – não são exceções e sim erros que jamais poderiam ter acontecido. ex.: estouro da memória.

Exception- as classes que deveriam aqui, lançar exceções e não erros de programação. Exemplo: tentar abrir um arquivo que não existe. Então, é lançado uma exceção verificada, porque a classe de leitura de arquivos deriva de Exception.

RuntimeException – são exceções que indicam erros de programas (não de lógica, pois senão não passaria pelo compilador). Esse tipo de exceção é conhecido como não verificada. Sendo assim, não é requisito declarar uma cláusula try{} e catch{}. Ex.: tentar converter “dois” em “2”.

Obs.: Implicitamente, todas as classes em java automaticamente já lançam uma exceção de RuntimeException.

Figura1 – Hierarquia Exceções (nao sou muito bom de desenho rs)

Espero que tenham gostado. Um abraço a todos e até o próximo. Abraços! Não deixem de acessar meu blog.

Opa! Pessoal! Dando continuidade a nossa série Refactoring, quando veremos mais uma situação onde devemos aplicar a técnica. A situação apresentada na série de hoje, normalmente acontece quando estamos realizando alterações constantes. Espero que gostem!

Lets go…

Posts relacionados:

Refactoring Série 1

Refatoração em código Java na prática – Nova Coluna Imasters!

Refatoração

Vantagens/Desvantagens e ferramentas

Refactoring e Manutenção de Software

Este post está dividido:

• Motivação do uso da técnica

• A mecânica para executar a técnica

• Um exemplo

Obs.: O nome da técnica terá como referência o sugerido por Fowler. Claro que, você programador pode dar o nome que achar conveniente. Por boas práticas, dei preferência manter a nomeação de um dos pais da refatoração.

Técnica: Mover método

Como já dito, normalmente acontece uma situação para aplicar essa técnica, quando acontecem alterações constantes que acabam resultando nesse cenário. Algumas vezes, temos um método sendo utilizado por mais recursos de outras classes do que pela classe onde foi definido. Em situações como essa se deve mover o método a fim de adequar seu uso a classe.

Motivação

Mover métodos é uma prática comum da refatoração. Normalmente, movem-se métodos quando as classes têm comportamento demais ou estão colaborando entre si. Movendo alguns métodos, ficam mais claros os objetivos e as responsabilidades de cada classe. Um ponto importante é que os métodos da classe devem ser examinados antes de serem mudados. Deve-se procurar métodos que pareçam referenciar outros objetos mais do que a classe na qual está inserido. Após encontrar um método candidato, é necessário avaliar os métodos que ele chama e os métodos que o chamam a fim de definir com qual objeto o método interage mais.

Mecânica

A refatoração mover método foi executada com os passos a seguir:

a) examinar se os atributos da classe de origem são utilizados pelo método e se esses

devem ser movidos também;

b) procurar declarações dos métodos nas subclasses e superclasses da classe de

origem;

c) mover o método para a classe destino;

d) ajustar o método a fim de funcionar na nova classe;

e) compilar e testar;

f) caso o método seja removido da classe de origem, as referencias ao método

devem ser substituídas por referências de sua nova localidade;

g) compilar e testar.

Exemplo

O código code 1 apresenta um código não refatorado onde teremos diversos novos tipos de contas. Cada uma das quais com suas próprias regras para calcular o custo do saque a descoberto. Observe que na linha 3, o método cobrançaPorSaqueADescoberto está usando mais recursos de outra classe onde não foi definido.

1. class Conta . . .

2. private TipoConta tipo ;

3. double cobrancaPorSaqueADescoberto(){

4. if(tipo.ePremium()){

5. double resultado = 10;

6. if( diasDescorbetos > 7)

7. resultado += (diasDescorbetos – 7) *0.85;

8. return resultado;

9. }else return diasDescorbetos * 1.75;}

10.double tarifaBancaria(){

11. double resultado =4.5;

12.if(diasDecorbetos > 0)

13. resultado += cobrancaPorSaqueADescoberto();

14.return resultado}

code 1 – Método que tem recursos demais sobre outra classe (código não refatorado)

O code 2 apresenta o código refatorado onde o método (cobrancaPorSaqueADescoberto) foi transferido para a class TipoConta como pode ser visto na linha 2 à 13. A referência tipo foi removida na linha 4. Agora a class Conta retorna o método cobrancaPorSaqueADescoberto na linha 18. Veja a seguir como ficaram as classes:

1. class TipoConta …

2. double cobrancaPorSaqueADescoberto(int diasDescobertos){

3. if(ePremium()){

4. double resultado = 10;

5. if( diasDescorbetos > 7)

6. resultado += (diasDescorbetos – 7) *0.85;

7. return resultado;}

8. else return diasDescorbetos * 1.75;}

9. double tarifaBancaria(){

10. double resultado =4.5;

11.if(diasDecorbetos > 0)

12. resultado += cobrancaPorSaqueADescoberto();

13.return resultado;

14.}}

15.class Conta{

16.private TipoConta tipo ;

17.double cobrancaPorSaqueADescoberto(){

18.return tipo.cobrancaPorSaqueADescoberto(diasDescorbetos);}}

code 2 Movendo método para a classe onde está sendo mais utilizado

Agora o código está mais objetivo de na classe mais apropriada concorda? Bom, vou ficando por aqui! Espero que tenham gostando dessa série! E fica ai mais uma vez os efeitos que Refactoring causa dentro do ambiente de desenvolvimento. Um abraço a todos e até o próximo post! Have a nice weekend everybody 🙂

Salve! Salve! Pessoal! Antes de apresentar o primeiro post, quero dar um feliz ano novo a todos, com muita paz e saúde.

Durante o período de 30/12/08 à 04/01/09 que fiquei camilo-off, onde estava curtindo um pouco essas férias, fique pensando, qual será o primeiro post para 2009? Ai veio, “que tal completar aquela série refactoring 2008? Porém, com a parte prática conforme prometi”. Sendo assim, a promessa está sendo paga. Rs… Hoje vou mostrar algumas práticas de refactoring a nível de código. Claro que será em Java code, como dizem, será “mão na massa”. Veremos algumas situações que devemos aplicar a técnica quando estamos programando.

Para ficar mais emocionante coloquei o assunto em série, sendo esta, a primeira de outras que teremos. Um livro que recomendo para quem deseja estudar o assunto é o do Fowler, é realmente fantástico esse livro.

Lets go…

Link Recomendado

Refatoração

Vantagens/Desvantagens e ferramentas

Refactoring e Manutenção de Software

Refatoração em código Java na prática – Nova Coluna Imasters!

Obs.: serão apresentados apenas trechos de códigos referentes ao assunto. Não há necessidade de apresentar toda linha de códigos de uma classe, uma vez que estes não refletem no assunto em questão.

Para quem não lembra, o que é refactoring lá vai uma breve descrição. Para maiores informações sobre, basta acessar os links acima.

Breve descrição

Refactoring: é o processo de alterar um Software sem mudar seu comportamento. Um Software refatorado deve executar da mesma forma que antes da aplicação da técnica. A vantagem de aplicar essa técnica dentro do ambiente de produção é que ela promove um desenvolvimento rápido e facilita na manutenção do Software.

Este post está dividido:

• Motivação do uso da técnica

• A mecânica para executar a técnica

• Um exemplo

Obs.: O nome da técnica terá como referência o sugerido por Fowler. Claro que, você programador pode dar o nome que achar conveniente. Por boas práticas, dei preferência manter a nomeação de um dos pais da refatoração.

Técnica: Expressão Condicional

A situação para aplicar essa técnica, é algo bastante comum. Quem aqui nunca ouviu e/ou desenvolveu expressões condicionais retornando o mesmo resultado?

Ao se deparar com uma situação acima, temos que aplicar a técnica de refactoring para deixarmos o código mais limpo e facilitar o entendimento. Veja abaixo a real motivação para aplicação da técnica.

Motivação

Em alguns blocos de códigos é possível encontrar expressões condicionais remetendo a um mesmo resultado. Assim, condensar as expressões em apenas uma, pode ser considerado uma técnica de refatorar. Condensar as expressões condicionais é importante pelos seguintes motivos:

a) Primeiro: com apenas uma expressão condicional torna a verificação mais clara, mostrando o que está realmente executando uma única verificação. Ao contrário quando se tem condições separadas, onde transmite a impressão de ter verificações independentes.

b) Segundo: com as expressões condensadas, fica mais fácil de aplicar outras técnicas de refatoração, a partir do momento em que se têm códigos mais claros.

Mecânica

A mecânica da técnica de refatoração a seguir, é para uma situação semelhante ao code 1.

a) verificar se nenhuma das expressões condicionais causa efeito colateral, ou seja,

alteração em uma das mudanças faz o programa não funcionar como antes. Caso haja,

esse procedimento não deve ser executado;

b) substituir um conjunto de condicionais por apenas uma expressão condicional usando

operadores lógicos;

c) compilar e testar.

Exemplo

O code 1 apresenta expressões condicionais remetendo o mesmo resultado, conforme é apresentado nas linhas 2, 3 e 4, o que dificulta a leitura do código. Imagine isso com mais expressões, onde há mais linhas para serem compreendidas. O code 1 apresenta um código não refatorado.

…

1. double valorPorIncapacidade(){//calcular o valor incapacidade

2. if(_antiguidade <2) return 0;

3. if(_mesesIncapacitado > 12)return 0;

4. if(_eTempoParcial)return 0;}}

…

code 1 – Expressões condicionais que retornam o mesmo resultado. (Código não refatorado)

Código refatorado code 2 consolidou as expressões condicionais utilizando o operador “OU” para obter único resultado, como pode ser visto nas linhas 2 e 3.

1. double valorPorIncapacidade(){//calcular o valor por incapacidade

2. if((_antiguidade < 2)||(_mesesIncapacitado > 12)|| (_eTempoParcil))

3. return 0;

4. }

code 2 – Consolidar Expressão Condicional. (código refatorado)

Observe ambos os codes e veja à essência e os efeitos que a aplicação da técnica de refactoring promove. Qual código está mais fácil de ler? A manutenção se tornou mais fácil?

Muitas vezes estamos programando e não nos damos conta disso. Claro que isso pode parecer algo insignificante, pois, estamos aplicando a técnica em apenas 04 linhas de códigos. Mas, na prática sabemos que é comum encontrarmos expressões condicionais com mais de 20 linhas remetendo o mesmo resultado. Então a partir de agora ao identificar uma situação assim basta refatorar e tornar seu ambiente de produção mais saudável.

Vale salientar que a técnica de refatoração não é algo fechado, ou seja, ela não define quantas expressões condicionais são necessárias para aplicar a técnica. Isso tudo vai depender da equipe de desenvolvimento definir quando deve ser aplicada a técnica. Essa regra também vale para outras técnicas de refactoring.

Bom, vou ficando por aqui! Um abraço para todos! Espero que tenham gostado e até a próxima. Have a nice week, everybody!

Salve! Salve! Mas uma semana e estou aqui marcando presença com mais uma serie Refactoring.  Onde vou abordar como Refactoring influencia na manutenção de software e a opinião de alguns autores consagrados no mundo T.I pensam a respeito. Espero que gostem dessa ultima série refactoring.

Recomendo quem puder compre o livro do Fowler, realmente é um excelente livro.  E para os que não “curte”  livro inglês a tradução está de parabéns, eu tenho tanto o inglês quanto e português e fiz comparações de vários capítulos com a obra original e nada de erros grosseiros no processo de tradução.

Let’s GO…

Outros post da Série/Other post of the series

1.Refatoração

2.Vantagens/Desvantagens e Ferramentas

Summary

This article presents as a refactoring can contribute for maintenance of software. Refactoring help a develop software more fast because avert that the project of the system if damage, bettering the process of maintenance and optimization of the time spent in the developing. Last refactoring contributes for maintenance of the software.

Cenário Manutenção Software

Segundo Maia (2004), o custo e a complexidade de se manter um Software são amplamente reconhecidos. Estima-se que cerca de 50% do tempo de um engenheiro de Software é gasto com tarefas de manutenção e compreensão de código.

De acordo com Pressman (1995) a manutenção de Software pode ser responsável por mais de 70% de todo o esforço despendido por uma organização de Software. E essa porcentagem continua aumentando à medida que mais Software é produzido. Para este autor manutenção de Software é bem mais que “consertar erros”. Há quatro atividades que são levadas a efeito depois que o Software é liberado para uso. São elas:

-A primeira atividade de manutenção ocorre por que não é razoável prevenir que a atividade de testes do Software decorrerá todos os erros latentes num grande sistema de Software. E durante o uso de qualquer programa, erros ocorrerão e serão relatados ao desenvolvedor.

-A segunda atividade que contribuiu para uma definição de manutenção ocorre por causa da rápida mudança que é encontrada em cada aspecto da computação. Novos sistemas operacionais, novas gerações de hardware por exemplo.

-A terceira atividade quando um pacote de Software é bem-sucedido. À medida que o Software é usado, recomendações de novas capacidades de modificações em funções existentes e de ampliações gerais são recebidas dos usuários.

-A quarta atividade de manutenção ocorre quando o Software é modificado para melhorar a confiabilidade ou a manutenção futura, ou para oferecer uma base melhor para futuras ampliações.

O custo da manutenção de Software tem aumentado firmemente durante os últimos 20 anos. Durante a década de 1970, a manutenção era responsável por um índice entre 35% e 40% do orçamento de Software para uma organização de sistemas de informação. Esse valor pulou aproximadamente 60% durante a década de 1980. Se nada for feito para melhorar a manutenção, muitas empresas gastarão 80% de seus orçamentos de Software em manutenção. Quanto mais eficiente for à fase de manutenção do Software mais fácil é de mantê-lo. (Pressman, 1995)

Refatoração e Manutenção

A refatoração pode ser considerada uma técnica ou ferramenta de auxilio no desenvolvimento e manutenção, contribuindo para o tempo de vida do Software, já que o acréscimo de novas funcionalidades é de maneira fácil e rápida. (FOWLER, 2004)

Para Pressman (1995), quanto mais eficiente for à fase de manutenção do Software mais fácil é de mantê-lo.

Em seu livro Fowler diz que um sistema mal projetado normalmente precisa de mais código para fazer as mesmas coisas muitas vezes porque o mesmo código foi duplicado em diversos lugares diferentes. Quanto mais difícil é visualizar o projeto a partir do código, mais difícil será preservá-lo e mais rapidamente ele se desestruturará. A eliminação de código duplicado é um aspecto importante na melhora do projeto, sendo que reduzindo a quantidade de código faz uma grande diferença sobre a manutenção desse projeto.

Fowler (2004) defende que quanto mais código houver em um Software, mas difícil será modificar corretamente.

“[…] Reduzir a quantidade de código faz, todavia, uma grande diferença sobre a manutenção desse código. Quanto mais código houver, mais difícil será modificá-lo corretamente. Há mais código para ser entendido. Você altera trecho de código aqui, e o sistema não faz o esperado porque faltou alterar em outro lugar que faz a mesma coisa em um contexto levemente diferente […]”. (FOWLER, 2004, p. 54)

Sendo assim a refatoração ajuda a desenvolver Software mais rapidamente porque evita que o projeto do sistema se deteriore, melhorando o processo de manutenção e otimização do tempo gasto no desenvolvimento. Enfim refactoring contribui para manutenção do software.

Tem dúvidas por que usar a técnica de refactoring no ambiente de desenvolvimento?

Infelizmente a série de refactoring foi curta, mas aqui foi apenas o first time. Em breve venho com a segunda parte da série onde pretendo abordar outros pontos importantes referente à técnica de refactoring e apresentá-la a nível de código.  Recebi alguns emails perguntando a diferença entre Extreme Programming (XP) e Refactoring veja abaixo para quem dúvida a respeito das praticas:

XP

Uma metodologia que foi responsável pelo crescimento da visibilidade de aplicar refatoração foi Extreme Programming (XP). Uma das principais idéias Extreme Programming é que o desenvolvedor deve trabalhar em apenas um caso de uso por vez e assim deve projetar o Software para que fique coerente com o caso de uso em questão. Se um determinado caso de uso não ficou bem projetado, deve-se aplicar refatorações até que o caso de uso possa ser implementado de uma maneira coerente. XP é uma metodologia que é baseada em mudanças. Um dos principais pilares de XP é a continua e agressiva aplicação de refatorações. Sem elas, XP não funcionaria. (MAIA, 2004)

Reflexão:

Espero que a série refactoring tenha contribuído para a vida de você programador, desenvolvedor etc. E que a partir de “ontem” essa técnica venha fazer parte do ambiente de desenvolvimento.

O ponto que me chamou atenção, é que as empresas de T.I cobram varias siglas ao fazer um processo de admissão, porém de 10 vagas que consultei nos maiores sites de empregos de T.I nenhuma delas “queriam saber se você programador, desenvolvedor sabe algumas das boas práticas de desenvolvimento”.

O máximo que foi possível encontrar nas vagas era Design Patterns. Achei isso preocupante. Mesmo que uma empresa tenha uma política interna de desenvolvimento é importante que essa política seja baseada em algo, por exemplo: na técnica de refactoring, XP. Não considero boas práticas as empresas que definem:

– Aqui somente usamos IDE X

– E todas as variáveis de instancia são private e deve ser escrita da forma Y

– Os acessos as variáveis somente por método

Um bom programador já DEVE já saber isso por natureza. Já que essa nomeação vem lá da O.O

O que quero chamar atenção para as empresas de T.I um engenheiro, um arquiteto etc. Que antes de cobrar tantas siglas (JSF,JSP, SERVLET etc) analise também a questão se esse profissional sabe alguma das boas práticas de desenvolvimento a nível de código. Desenvolver uma aplicação e colocar para funcionar é apenas 20% do projeto os outros 80% do trabalho vai estar na manutenção (se o desenvolvedor morrer ou sair da empresa o projeto pode falhar se ninguém entender o código desenvolvido).

Recentemente peguei uma aplicação de um “bom programador” (meu amigo) que ela atendia todos os pré-requisitos do cliente (para o cliente melhor aplicação do mundo, já que atendia todas as suas necessidades). Porém fui analisar o código (apenas por curiosidade) meu deus, quase tinha um infarto. De tanta duplicidade, modificadores aplicados de forma indevida, e os tamanhos de cada comentário daria um livro.

Tenham bastante cuidado com isso. Eu acredito que no futuro teremos vagas somente para “Reestruturar Software sem mudar o comportamento observável”.

Abraço! E até próximo post!

Referências

Fowler (2004)

Pressman, R. S. (1995). Engenharia de Software (3ª ed.).

MAIA, P. H. (2004). REFAX:Um arcabouço para desenvolvimento de ferramamentas de refatoração baseado XML. Programa de Pós Graduação em Ciência da Computação . Ceará, Fortaleza: UFC

Salve! Salve! Dando continuidade a série Refactoring, hoje vou abordar as vantagens/desvantagens e as ferramentas que temos disponíveis. Quero chamar atenção no primeiro tópico do post: Vantagem da Refatoração. Quis fazer um pouco diferente ao invés de pegar as vantagens de refactoring e tentar convencê-lo de usar ou apenas mostrá-las. Acabei fazendo diferente, não vou dizer de forma direta as vantagens de refactoring você como bom programador vai refletir sobre as abordagens dentro do tópico, e daí percebam onde entra o porquê de você adotar refactoring e seus respectivos benefícios no seu ambiente de desenvolvimento.

O motivo que fiz isso é que alguns/muitos profissionais de T.I sabem da existência de refactoring, sabem das vantagens que assistiu em alguma palestra ou leu um artigo na web/revista, porém após ter visto nada mudou em sua vida como programador. E eu sou apenas mais um transmitindo aquilo que ele já viu várias vezes.

O que quero é que você programador/analista etc. após ler reflita, pegue um código seu e se pergunte será preciso refatorar meu software?

Let’s GO…

Summary

This article presents the vantages/disadvantage and the tool that have available for refactoring. The list of the tool is in the end this article.

There are four parts that became the program hard of work. See below:

– Program that is hard of read the level of code

– Program that have the logic duplicate

– Logic conditional: program with logic conditional complex is hard of work.

The tool for refactoring help the project letting more elastic.

Vantagens da Refatoração

Refatorar é o processo de pegar um programa em produção e agregar a ele valor, não por meio da alteração de seu comportamento mais dando qualidades que nos permitem continuar desenvolvendo rapidamente. É preciso ter programas fáceis de ler a nível de código e que tenham a lógica especificada em apenas um lugar.

“Programas têm dois tipos de valor: o que eles fazem por você hoje e o que podem fazer por você amanhã, na maior parte das vezes quando estamos desenvolvendo um Software focalizamos no queremos que o programa faça hoje.” (Beck,2000)

Nas palavras de Beck [2000 apud Fowler, 2004, pg.58] “Se você consegue fazer hoje o trabalho de hoje, mas o faz de uma maneira na qual possivelmente não conseguirá fazer amanhã o trabalho de amanhã, é considerado perdido”. Para este autor refatorar é uma maneira de sair dessa situação. (se achou confusa a citação acima leia com mais calma, parece frase de índio então busque ler pausadamente buscando o gancho e perceba o que está entre linhas sobre afirmação do Dr. Beck. Frases de Drs. são assim mesmo rsrs)

Beck (2000), identifica quatro partes que torna os programas difíceis de trabalhar/modificar:

– Programas que são difíceis de ler à nível de código

– Programas que tem lógica duplicada

– Inclusão de novas funcionalidades: Programas que para inclusão de novas funcionalidades, requerem a alteração de código existente, são difíceis de modificar

– Lógica condicional: Programas com lógica condicionais complexas são difíceis de modificar.

Existe ou não existe vantagem de aplicar refactoring?

Desvantagem

Segundo Fowler (2004) não há experiências em quantidade suficiente para definir onde as limitações se aplicam a técnica de refatoração. Abaixo apresento algumas das áreas citadas por Fowler onde este autor considera que são difíceis (isso não quer dizer que é impossível) de aplicar a técnica de refatoração.

– Banco de dados: É uma área problemática para refatoração. A maioria das aplicações comerciais são altamente acopladas ao esquema do banco de dados que as suporta. Esse é um motivo pelo qual bancos de dados são difíceis de modificar. O outro motivo é a migração de dados, onde alterar o esquema do banco de dados lhe força a migrar os dados, o que pode ser uma tarefa longa e pesada. (Observe que há profissionais, cientistas trabalhando nesse caso, confira a matéria sobre o tema no blog Visão ágil)

–Alterando interface: Um problema com a interface é se estiver sendo usada por código que não é possível encontrar e alterar. Tendo assim se torna uma interface publicada onde não é mais possível alterá-la com segurança e sim apenas modificar a chamada nos métodos que a invocam e isso dificulta o processo de refatoração. Se uma refatoração alterar uma interface publicada tem que conservar tanto a interface antiga quanto a nova e isso leva ao caminho da duplicação de código.

– Linguagens não orientadas a objetos: São mais difíceis de reestruturar, pois fluxos de controle e de dados são fortemente interligados e por causa disso as reestruturações são limitadas a nível de função ou bloco de código.

Há outras áreas citadas por Fowler que você encontra no livro do autor.

Ferramentas para Refatoração

Mas Camilo eu tenho uma duvida, vou ter que refatorar na “mão grande”?

R- Também. Mas não é a única opção.

Você já imaginou refatorando um programa com 2 mil linhas de códigos? É complicado e pode atrasar o projeto certo? Para isso temos as algumas ferramentas automatizadas para refatoração. Antes de apresentar as ferramentas que dão suporte à linguagem Java, veremos o que alguns autores dizem a respeito do uso dessa técnica e no final temos o objetivo geral das ferramentas.

Refatorar com suporte de uma ferramenta automatizada é diferente da refatoração manual. Primeiro que a refatoração à mão consome muito tempo em programas grandes. (Fowler, 2004)

As ferramentas automatizadas diminuem o risco de erros e inconsistência no código, além de poupar um grande trabalho em se tratando de sistemas com centenas ou milhares de linhas de códigos. (Beck,2000)

Segundo Roberts (1997 apud Fowler, 2004, pg.342) com as ferramentas de refatoração automática o projeto se torna mais elástico, já que alterá-lo é muito menos custoso, sendo assim estender o projeto adicionar flexibilidade no futuro sem grandes custos. Para este autor o principal propósito de uma ferramenta de refatoração é permitir ao programador, refatorar código sem ter que testar novamente o programa.

Abaixo a relação das ferramentas de refatoração para Software Java:

List tool:

-XRefactoring (xref-tech)

– IntelliJ IDEA (IntelliJ IDEA)

-IBM Visual Age for Java (IBM)

Abraço a todos! Vou ficando por aqui espero que tenham gostando e até próximo post (o ultimo da série Refactoring).

Thanks!

Referências

IntelliJ IDEA. (s.d.). http://www.jetbrains.com/idea/index.html

IBM. (s.d.). http://www-142.ibm.com

xref-tech. (s.d.). http://www.xref-tech.com/

Fowler (2004)