Blog

Serie 1: SOA – Arquitetura Orientada a Serviço

Salve, salve, amigos/colegas/leitores. Hoje darei inicio a uma nova série: “Série SOA”. Resolvi escolher esse tema por alguns motivos: primeiro por ser uma tecnologia nova (apesar de existir a mais de 6 anos, há alguns profissionais de T.I que nunca ouviu falar, ou que já ouviu mas não tem ideia do que seja); segundo é que a tecnologia já apresenta bons e ótimos alicerces dentro do ambiente T.I X Negócios.

Além de ser uma boa área para monografia (era o meu há 2 anos, mas por força do destino dos meus orixás acabei mudando) :D.

Espero que gostem do post e da tecnologia, lembrando: o que será apresentado nessa série é a ponta de um iceberg do mundo SOA.  Nesse primeiro post  temos uma pequena historinha e o conceito sobre a arquitetura.

Let’s GO…

Summary

This article presents technology SOA. This first series is presenting history and concepts about Service Oriented Architecture – SOA. Second ANSI/IEEE 2002(American National Standards Institute) is one architecture of the software about basic of as the component fundaments of the one system if relate.  The point leading in the application of the business focus: reuse, reduce of costs of developing and maintenance become solution of business more agile and easy of implements having opportunity of business. In the case SOA is adopted by people.

 

História SOA

Uma realidade recente, de pouco mais de seis anos, a Arquitetura Orientada a Serviços, ou como é comumente conhecida, o SOA (Service Oriented Architecture), chegou ao mundo corporativo paralelamente a uma mudança de postura que tomava conta das empresas em relação à Tecnologia da Informação e sua influência nos resultados. A TI, como já se sabe, é alvo de constantes transformações e não obstante demanda sempre melhoria ao elo dos interesses da empresa.

Com o passar dos anos, o objetivo é, cada dia mais, encontrar tecnologias que garantam um desenvolvimento com maior eficiência dos negócios e agreguem valor aos serviços oferecidos. Nesse contexto, teoricamente a tecnologia poderia ser vista como uma ferramenta a favor dos processos corporativos. Mas nem sempre é assim.

Há uma problemática que está freqüentemente no cotidiano dos departamentos das empresas e que inverte a ordem de quem deveria estar a serviço de quem. Os processos, sistemas e ações preestabelecidas geradas pela Tecnologia da Informação são, muitas vezes, tão inflexíveis e baseados em um padrão tão uniforme, que em vez de atenderem diferentes e mutantes demandas das corporações, acabam por fazer com que os negócios se adequem a elas.

Negócios e TI

O grande desafio desse cenário é encontrar uma solução que seja compatível e flexível ao negócio de forma a se encaixar e a remodelar os processos dos diferentes departamentos, quando necessário. Substituir os sistemas legados para que eles se encaixem a essas novas demandas que surgem com o crescimento do negócio, pode ser, além de caro, uma ação que resulte em ineficiência. O conceito de SOA permite encontrar uma solução relativamente barata e com um custo-benefício maior quando se refere a sistemas que precisam conversar entre si e processos que demandam maior flexibilidade e agilidade para atender as revoluções do mercado.

A definição da arquitetura, de forma prática, pode ser colocada como um desenvolvimento orientado a serviços. Isso significa que as aplicações estarão alocadas de uma forma interdependente, reflexo de uma infra-estrutura de tecnologia preestabelecida e pensada para criar serviços com flexibilidade suficiente para serem reutilizados entre os sistemas. Assim, com SOA, é possível acessar apenas uma parte dos serviços existentes, sem a necessidade de utilizar o processo completo.

Estrutura diferenciada

Quando uma empresa opta por utilizar o conceito, imediatamente se anula a questão da TI não acompanhar os negócios por não ter capacidade de tratar um processo como um todo. Com ele, a estrutura anterior fica para trás, com os muitos sistemas distintos cuidando de pequenos passos do processo e sendo redundantes entre si, além de exigir uma base de dados para cada um, dando lugar a maior inteligência e a otimização do ambiente de Tecnologia da Informação.

Um exemplo interessante da aplicação do assunto é observar um mecanismo de recrutamento e seleção do RH. Isso envolve cadastro de candidatos, recrutamento, entrevista, testes, seleção e contratação. Todos esses processos são feitos com o objetivo de fazer a contratação de um funcionário específico. Porém, como reprogramar esse caminho quando o funcionário a ser contratado é uma mão-de-obra que já trabalha na empresa e precisa apenas ser transferida de área?

Nesse caso, algumas fases dessa linha de contratação seriam excluídas, como por exemplo, cadastro do candidato e seleção. Para modificar esse padrão, tradicionalmente era necessário fazer uma mudança manualmente para driblar os processos preestabelecidos. Já com a arquitetura orientada a serviços, basta utilizar apenas algumas partes desse processo já existente, de acordo com a granularidade do sistema.

Conceito

Definir Arquitetura Orientada a Serviços por vezes é complicado, já que se trata de um conceito abstrato que pode ser utilizado de diversas formas e se transformar em ferramentas específicas de acordo com o negócio e com a empresa que decide adotá-lo. Segundo o ANSI/IEEE 2002 (American National Standards Institute), uma arquitetura de software trata basicamente de como os componentes fundamentais de um sistema se relacionam intrinsecamente e extrinsecamente.

Nesse contexto, os aplicativos e rotinas são disponibilizados como serviços em uma rede de computadores, que pode ser a Internet ou mesmo intranet, permitindo uma comunicação por meio de padrões abertos. Por esse motivo, o WebService é um recurso bastante utilizado para a criação dessa estrutura.

Tecnicamente SOA é um paradigma para organização e utilização de competência distribuída que estão sob controle de diferentes domínios proprietários.

De um modo geral as pessoas ou as organizações criam competências para resolver ou suportar uma solução para problemas que encontram no decorrer de seus negócios. A arquitetura orientada a serviço (SOA) torna possível transformar aplicações monolíticas rígidas em componente de softwares flexíveis, permitindo a interoperabilidade entre diferentes tecnologias.

O ponto crucial nas aplicações de negócios enfoca: reutilização, a redução de custo de desenvolvimento e manutenção, torna soluções de negócios mais ágeis e fáceis de implementar, viabilizando as oportunidades de negócio, ai que SOA é adotado pelas entidades (pessoas e organizações).

As organizações e as pessoas em nosso tempo visam os seguintes pontos para um negócio: reutilização, custo x beneficio, segurança e flexibilidade, esses são os pontos cruciais por empreendedores de negócios.

Enfim SOA é uma metodologia que visa maximizar a reutilização de serviços existentes e a integração com novos serviços para aumentar a eficiência e produtividade de uma empresa.

SOA tem por objetivo modelar a corporação como uma coleção de serviços que ficarão disponíveis para uso de toda a companhia. Uma vez montada essa arquitetura não é mais necessário construir novas aplicações desde o início (como o exemplo citado de RH anteriormente), elas serão montadas a partir de serviços publicados (internos ou externos).

Para ficar, mas claro dentro do SOA, Serviço é um conjunto de funcionalidades oferecido por um componente, apresentando características como:

-Invocação somente através da interface;

-Interface endereçável em uma rede (independente de localização);

-É interoperável (independente da plataforma);


Referencias:

http://www.sinfic.pt/SOA/arquitectura-soa.html

http://www.sinfic.pt/SOA/arquitectura-soa.html

http://www.pcs.usp.br/~pcs5002/oasis/soarm-csbr.pdf

Revista mundo Java numero 18 – Ano III

Um abraço a todos e espero que tenham gostado. Na série 2 apresentarei os benefícios!

Série 3 Refactoring e Manutenção de Software

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

Série 2 Refactoring: Vantagens/Desvantagens

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)

Serie 1:Boas Práticas com Refactoring

Olá Pessoal! Hoje vou falar sobre uma técnica que alguns conhecem  apenas teoricamente, uns usam constantemente e outros que nunca ouviram falar. A  nova série do blog é Refactoring. Ops!O que é  isso?  

Refactoring é o modo de você mudar a estrutura interna de seu software sem alterar seu comportamento observável. Você usa essa técnica quando você quer melhorar a legibilidade do código do software. Mas vale lembrar que Refactoring não usada para consertar erros e sim para prevenção. Com ou sem Refactoring seu software deve funcionar da mesma forma de antes ter aplicado a técnica.

 Nem todos os programadores conhecem  ou sabem aplicar a técnica refactoring, devo confessar que não conhecia a técnica antes de novembro/2007. Mas após uma discussão com um amigo sobre o assunto me interessei sobre o tema, dei inicio aos estudos que virou tema de minha monografia e que passou ser uma pratica constante no desenvolvimento de software. Tornou-se uma mania ao ver um código bagunçado e refatorá-lo. Vale salientar que não sou um experts na técnica me considero um mero estudante e curioso com a técnica. 

Espero que gostem da série Refactoring e que ela venha contribuir no seu ambiente de desenvolvimento de software. 
Let’s GO…

Summary

This article presents the technical of refactoring. Refactoring is one process of the restructure the system without changes your operation. Second Fowler (2004) refactoring into the software more easy of understand and change. One user or a programmer not is capable of say that something changed in the software. The technical of the refactoring help in the legible of code. For Fowler the refactoring is one element-key in process of the developing of software.

Sites/Livros:

http://www.refactoring.com

Livro Fowler

Introdução

Algumas profissionais de T.I acreditam que desenvolver um software é sentar na frente do computador e sair codificando. Já alguns acreditam que desenvolver software deve seguir o mesmo processo de linha de montagem de carro como  no filme tempos modernos.

Mas  bons desenvolvedores de software sabem que esse não  é o caminho correto. Desenvolver software requer planejamento e esse pode ser alterado de acordo com o ciclo de vida do software então o ambiente de desenvolvimento não é algo estático. Quando nasce um novo requisito uma parte do projeto ou todo o projeto passa a sofrer alterações e para executar esses novos requisitos é necessário planejar. Senão você desenvolvedor pode entrar em buraco sem saída com o software.

Para não entramos nesse “buraco” temos a refatoração que vem auxiliar no aperfeiçoamento do código-fonte minimizando as chances de novas falhas serem introduzidas no projeto. Refactoring contribuir para processo evolutivo do software, pois as técnicas de refatoração quando aplicada  de forma correta ao software aumenta consideravelmente seu tempo de vida útil, sua extensibilidade e modularidade.

Definição

Refatoração é o processo de reestruturar o sistema sem alterar suas funcionalidades. Mas Fowler (2004) vai um pouco mais além. Segundo este autor refatoração torna o Software mais fácil de entender e modificar. Para ele, apenas as mudanças feitas para tornar o Software mais fácil de entender são consideradas refatoração. A refatoração não altera o comportamento observável do Software. Esse ainda executa a mesma função de antes. Qualquer usuário seja ele final ou programador não é capaz de dizer que algo mudou.

Fowler defende que a refatoração é um elemento-chave no processo de inteiro desenvolvimento de software. O autor vai além e afirma que um bom projeto vem antes mesmo de sua codificação. Desenvolver software requer planejamento. É importante dizer que  refatorar é um “alicate de prata” que ajuda a manter o código seguro, porém a técnica de refatoração não cura todos os problemas no desenvolvimento de Software, mas é uma ferramenta valiosa.

Refatoramos para:

– Melhorar o projeto do Software: um projeto sem refatoração termina por se deteriorar à medida que as pessoas alteram o código e sem uma compreensão total do projeto, do código, acaba desestruturando. A refatoração é uma forma para estruturar o código;

– Tornar o Software mais fácil de entender a nível de código eliminado códigos duplicados;

– Encontrar falhas rapidamente, a partir do melhoramento do código;

– Programar mais rapidamente;         

Quando Refatorar

Para Fowler (2004) decidir quando começar a refatorar e quando  parar é tão importante quanto à mecânica de refatoração. Explicar como apagar uma variável de instancia ou criar uma hierarquia é questões simples, porém tentar explicar quando deve fazer, não é algo tão consolidado. Em seu livro Fowler apresenta os problemas que podem ser resolvidos por uma refatoração, mas cabe ao analista de sistemas, programador, desenvolvedor a própria percepção sobre quantas variáveis de instâncias são demais, quantas linhas de código em um método são excessivos.  Abaixo vou apresentar algumas das dicas que considerei importantes citadas Kent Beck um dos criadores da Programação Extrema (Extreme Programming – XP), afirma que refatoração deve ser utilizada quando o “código cheira mal” (do inglês “bad smells in code”).

A refatoração deve acontecer quando…

Código duplicado: Quando tem o mesmo código em mais de um lugar, dificultando a manutenção e aumentando o numero de falhas durante a manutenção do Software.

Método longo: Quando um método tem muito código. Quanto maior for o método, mais difícil é entendê-lo.

Classes grandes: Quando uma classe tem muita coisa a fazer, normalmente há existência de muitas variáveis de instâncias.

Comando switch: Os comandos switch essencialmente levam a duplicação. É comum encontrar o mesmo comando switch espalhado por diversos lugares do mesmo programa.

Comentários: Os comentários nos conduzem ao código ruim. Comentários que estão no código sem explicar o porquê, são considerados supérfluos.

Nesse momento você pode estar se perguntado: “Tudo bem vi quando refatorar  e  onde a técnica pode contribuir para meu software, mais o por que de  fazer tudo isso?”

Veja…

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 e que ao longo das últimas três décadas mais de 60% dos custos de desenvolvimento de Software das organizações foram gastos com manutenção. Refatoração é o processo de mudar um Software de tal forma que melhore a estrutura interna sem, contudo alterar o comportamento externo. Portanto, é uma forma disciplinada de re-organizar o código, minimizando as chances de introduzir erros. Refatorar tem a vantagem de melhorar a estrutura do código, facilitando o reuso e diminuindo o tempo gasto com tarefas de manutenção. O termo refatoração é aplicado a sistemas orientados a objetos; para outros paradigmas de programação esse mesmo processo é descrito como reestruturação.

Percebeu o por quê?

Bom pessoal! Vou ficando por aqui, o assunto Refactoring é um pouco extenso e não pretendo abordar todo em um único post para não ficar cansativo. No próximo mostrarei mais sobre Refactoring  falando sobre as vantagens /desvantagens e as ferramentas  disponíveis.

Um abraço a todos!

Referencias:

Fowler

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

Série SCJP:Polimorfismo e Genéricos

Salve!Salve! Mais uma semana e estou aqui  com mais uma série Revisão SCJP. Conforme falei na semana passada, hoje o assunto é: polimorfismo e genéricos  onde veremos como eles trabalham juntos e  as diferenças em relação ao uso  de polimorfismo com array sendo assim é importante você programador Java saber essas diferenças. Somente um detalhe não esquecer que  genéricos está apenas a partir do Java 1.5.

Aproveitando, venho informá-los  que essa será a ultima coluna da serie Revisão SCJP, na próxima coluna abordarei outros assuntos, mas não precisa fazer essa cara de triste por que a série revisão SCJP voltará de vez em quando basta acompanhar o blog! O motivo é para não ficarmos abordando um único assunto.

Let’s go  fight!

Pré-Requisito

Instalação Java 1.5/superior

– Revisão SCJP  Genérico/Generics

Summary

This article presents as use polymorphism and generics. The use polymorphism with generics there is one big different when use polymorphism and array. You cannot create one collection as below:

List<Animal> l = new ArrayList<Dog>();

Same that Dog extends Animal you cannot do this in collections. Because is permit only create collection of same type. However, you can add one object of other type as long as this object extends the class of the type of your collection. See below:

class Animal{}

class Dog extends Animal{}

ArrayList<Animal> la = new ArrayList<Animal>();

la.add(new Animal());

la.add(new Dog());

This code compiles and execute because you have one collection of the same type and add one object that extends the type of collection.  Is very important that you have attention with question about polymorphism and generics in the exam because they can to get you confuse. In the end this article there is one link for download of the one list with several example of generics and polymorphism do download this list, analysis the code and after test each example.

Polimorfismo e Genéricos

Ao usar polimorfismo com genéricos é importante ter bastante atenção e “esquecer” temporariamente a regra que  é aplicada a um Array. Por exemplo:

Posso ter um Animal[] array, que pode aceitar qualquer tipo ou subtipo de Animal, mas em Conjuntos a coisa é diferente isso não funciona. Veja:

import java.util.ArrayList;

import java.util.List;

class Animal{}

class Dog extends Animal{}

class Poli{

public static void main(String agrs[]){

List<Animal> l = new ArrayList<Dog>();

l.add(new Animal());

l.add(new Dog());

}}

 Esse código não compila. Mas por quê?

Por que  você está tentando criar um conjunto que aceita tipos diferentes onde deveria ser de um único tipo. É normal você achar que deveria compilar já que Dog extends Animal, caso isso fosse um array de Animal não haveria problema algum mais  quando se trata de conjuntos o polimorfismo opera diferente. 

Eu costumo dar um exemplo bem pratico veja:

“Se você compra uma caixa de maçã(É-UM Fruta) e levar berinjela(É-UM Fruta) dentro dela, será que você ficaria furioso quando abrisse a caixa? Então o compilador(feirante) ele evitar esse transtorno (ao cliente) permitindo que dentro da caixa de maça fique apenas maçã, mais nenhuma fruta.”

import java.util.ArrayList;

import java.util.List; 

class Animal{}

class Dog extends Animal{} 

class Poli{

public static void main(String agrs[]){

Poli p = new Poli();

ArrayList<Animal> la = new ArrayList<Animal> ();

la.add(new Animal());

la.add(new Dog()); //aceita porque  Dog extends Animal

}} 

Coringa <?>

O uso do coringa permite receber qualquer tipo. Quando usa o coringa e extends estamos dizendo que é permitido receber qualquer  class que é subtipo daquela class ou uma interface que implementa aquela classe. Mas você não pode adicionar nada ao conjunto. Veja o que não compila:

import java.util.*;

class Carta{}

class Coringa extends Carta{}

class Jogo{

public void cha(List<? extends Carta> car){

car.add(new Carta());          } 

public static void main(String [] agrs){

Jogo j = new Jogo();

List<Carta> list = new ArrayList<Carta>();

list.add(new Carta());

j.cha(list);

}} 

Não compila porque usei < ? > sendo assim estou dizendo ao compilador que pode receber um conjunto de qualquer subtipo, porém JAMAIS adicioná-lo ao conjunto, nem que seja do mesmo tipo. 

Basta alterar essa parte do código para compilar veja:

public void cha(List<? extends Carta> car){

/* observe que não foi adicionado nada a minha lista*/ 

<? super tipo> 

Como temos o extends temos também uma palavra chave super para a notação <?> o qual permite que você adicionar ao conjunto apenas o que está acima daquele tipo.

import java.util.*;

class Carnaval{}

class Banda extends Carnaval{}

class Bloco extends Banda{}

class Chi{ 

public void carna(List<? super Banda> band){

band.add(new Banda());

band.add(new Bloco());} 

public static void main(String [] agr){

Chi ch = new Chi();

List<Carnaval> lis = new ArrayList<Carnaval>();

ch.carna(lis);}} 

Observe que meu método aceita qualquer tipo acima de Banda, porém não posso passar  Bloco porque eu informei que seria super e nao extends a Banda. 

Outro o ponto a observar aqui é que meu método aceitou  um argumento do tipo diferente. 

Está confuso? Experimente fazer essa alteração: 

List<Bloco> lis = new ArrayList<Bloco>();

E veja que o código não compila. Já que o método diz que não é permitido receber nada que não for super a Banda.

<?> – Qualquer Tipo: Permite receber qualquer tipo dog, cat, etc. Porém não posso adicionar(add) nada ao conjunto. 

import java.util.*;

class QuaCor{

public void ch(List<?> li){//nada de adicionar algo aqui} 

public static void main(String agr[]){QuaCor qc = new QuaCor();

List<Integer> li = new ArrayList<Integer>();

List<QuaCor> list = new ArrayList<QuaCor>();

qc.ch(li);

qc.ch(list);}}

Onde não posso usar coringas: 

Na  criação dos objetos: List<?> f = new ArrayList<? extends Animal>(); 

Usar coringas ? apenas:  Argumentos ,variáveis e tipos de retornos. 

List<? extends Animal> li = new ArrayList<Dog>(); 

ArrayList<?> list = new ArrayList(); 

ArrayList<? extends Girafa> g = new ArrayList<Gir>();

//não posso add nada aqui g.add(new Gir()); não compila

<Object>(aceita apenas Object) é diferente de <?> (aceita qualquer coisa). 

Quando você usa <?> pode receber qualquer tipo mais quando usa Object pode receber apenas Object se usar <? extends Object> pode ser qualquer tipo: Dog, Cat, Integer. Porém sem adicionar ao conjunto. 

Bom pessoal! Espero que tenha gostado da coluna e aprendido um pouco como funciona o polimorfismo com genéricos, no inicio acontece uma pequena revolução no cérebro já que com array o uso do polimorfismo é bem mais fácil. Mas com genéricos não é difícil a questão é se acostumar e ficar atento as regras e lembrar que o segredo de genéricos está no tipo do conjunto. No link abaixo deixei uma lista de classes  para você ficar ligado nas pegadinhas para o exame e erros que você pode cometer ao desenvolver uma aplicação usando genéricos e polimorfismo.

Um abraço e até a próxima!
Download – lista de classes