Blog do Andre Fonseca

Muitos programadores sabem o quanto criar configurações ou arquivos de configurações para flexibilizar as aplicações ou uso de apis é um trabalho árduo. Na maioria dos casos opta-se por arquivos de XML  cuja a sintaxe nem sempre é fácil de entender e muito desacoplada da classe que irá usá-la dificultando muito a compreensão do funcionamento do sistema.

Muitas pessoas (desenvolvedores) sempre procuram criar sistemas ou api que sejam capazes de atender a uma grande quantidade de cenários sem que hajam modificações diretas em seus fontes.  Para tanto, parametrizam em forma de configuração externas valores que o sistema deve usar que serão particulares para cada caso, exemplo:  nome do banco de dados, diretório onde ficam os arquivos de template, quantidade de dias que devem manter um dado no memória, mapeamento objeto relacional de um objeto, etc.

Na maioria dos casos essa parametrização ou configuração é possibilitada pela criação de arquivos XML, onde quem irá usar o sistema ou a biblioteca deverá preencher com os valores desejados. Isso faz com que o sistema torne-se flexivel e evita customizações em código para casos particulares.  Detendo-se mais no caso de bibliotecas, por exemplo, api de persitencia (mapeamento objeto relacional), esta forma de fazer é bastante útil, embora adicione uma grande carga ao desenvolver pois além de escrever suas classes e etc, também tem que escrever e gerenciar os arquivos de configuração daquela Dll ( ou jar se for caso de java, por exemplo).

Um outro aspecto que considero no uso de XML para configurações é que ele fica desacoplado demasiadamento do código. Para o caso de um sistema, issso é bom, pois o usuário não interessa, somente importa definir os parametros e é tudo. Para o caso de uma biblioteca a coisa muda um tanto de figura, pois se quer deixar sua aplicação com um entendimento claro e no caso aqui, a classe e sua parametrização ficam em arquivos separados.

Foi pensando nisso que as linguagens atuais começaram a tentar em suas novas versões criarem recurso de forma a facilitar este tipo de trabalho.  Neste contexto que temos as anotações, para o JAVA, e os atributos, para o .NET.

Anotações e atributos fazem o elo entra a implementação e a parametrização. Tornando o código claro, legível e compreensível.

As anotações ou atributos são metadados que adicionamos as nossa classe que nos permitem de através delas passarmos informações de parametrização e configuração.

No exemplo acima, minha classe tem um método que coloco um atributo que tem uma propriedade Sbrubles que pode receber um valor booleano. Depois, por Reflection, posso pegar os dados deste atributo e usar para fazer alguma coisa. Esse tipo de abordagem neste tipo de caso, é bem melhor por fica claro os parametros e sua associação. Além disso o trabalho reduz pois agora basta a própria classe para a implementação e para a configuração.

Em Csharp, para criar seu atributo, bastar criar uma classe que extenda a classe System.Attribute. Além disso, por meio de atributos na classe, é preciso definir se este atributo será ligado a metodo, classe, propriedade, etc, se pode se repetir, etc.  Exemplo:

E para ter acesso ao dados, você pode ter o seguinte codigo:

Confesso que não aguento mais, todas a vezes que me reuno com alguns amigos, participar daquelas discussões onde todos falam que tal linguagem é mal, outra boa, tal linguagem é melhor e outra pior. Isso só piora quando resolvem falar do Java. Parece que o salvador da pátria, até pouco tempo atrás, virou o vilão da história.

Me lembro bem que a quase 10 anos atrás, em quase toda empresa que ia, e propunha de fazer algo em Java, era como se tivesse cometido uma heresia. Ninguém aceitava.  Todos eram enfáticos em afirmar que  a linguagem era lenta, pesada demais,  pouco perfomante, e por ai seguiam.  Todos olhavam para o Java e acreditavam que iria morrer logo, pois não tinha como compertir com o Delphi (que dispontava na época), muito menos com o C++. Java estava quase que restrito aos ambientes acadêmicos, ou então, para aquelas empresas que se colocavam como vanguardistas da época.  Eu sou um bom exemplo disso:  meus primeiros contatos como desenvolvedor java foram para projetos acadêmicos.

Eis que então a tal da internet começou a avançar as passos largos, e o que era até então,  uma coisa timida em seu uso, foi tomando corpo.  No começo, ainda me lembro, daqueles sites “toscos”, todos em HTML, não havia nada dinâmico.  O pessoal usava o padrão cgi e codificava em C para tratar os dados que eram preenchidos nos formulários. Javascript, até onde me lembre, não tinha nada.  webmails, eram raros, maioria das coisa eram por meio de programas clientes (quem não lembra daquelas rotinas onde conectavamos, baixavamos os emails e depois lia e respondia. Ao terminar de responder, conectava novamente e enviava e sincronizava novamente).

Portal da UOL em 1996

Bem até que o pessoal da Java, fez os applets. Elas foram, na minha opinião, as verdadeiras responsáveis pelo sucesso que a linguagem tem hoje.  Graças aos applets que Java teve alguma projeção no mercado e seu crescimento não parou mais.  Tal crescimento se deve não somente pelas applets mas  por que eles nunca se contentaram em ser “cantores de uma só canção“. A equipe da Sun investiu pesado em recurso que fizessem do Java cada vez mais a melhor opção para desenvolver sistemas distribuidos, cliente-servidor.

Bom, mas porque escrevi tudo isso? Para mostrar que: primeiro que Java já foi uma tão inovadora e revolucionária, como as linguagens atuais; Java percorreu um longo caminho para ser oque é hoje;  Assim com hoje para algumas tecnologias emergentes, Java enfrentou preconceitos e barreiras ao seu uso; todos diziam que ela não iria sobreviver ao mundo corporativo e que não escalava, assim como alguns linguagens hoje; etc. Por isso, não sou muito fã de  artigos, discursos, o que mais seja, dizendo que Java é o novo Cobol.  A tecnologia conquistou o seu espaço provando ser util para muitas coisas.

Onde está o problema então? As pessoas que abandonaram o Java ou que não o querem estão malucas?

Bem, claro que não. A reclamação, ou melhor, a observação que os desenvolvedores mais revoluionário e vanguardistas tem feito são válidas.  Porém acredito que, alguma delas, são mal direcionadas. A tecnologia, ou como ela se apresenta hoje, a plataforma Java ela em si não é culpado pelo uso que lhe é dado.  Sendo assim, foram os desenvolvedores que tentaram, e ainda tentam, torná-la a bala de prata.  Que vejo hoje, é que a melhor coisa é entendermos que não precisamos somente usar a mesma “ferramenta” para resolver todos os problemas. Podemos mesclar, e usar o melhor de cada linguagem.  Podemos nos aproveitar de todos poder do Java e Python ou  Ruby, etc.

Java não é ruim.  Java não é o novo Cobol.  A questão que penso é :  Os programadores Java, alguns, querem transformar-se em consultores como era o pessoal de Cobol.  O pessoal que usa a tecnologia que está fazendo que ela seja vista de forma negativa.  São as pessoas que  forçam as situações que vemos hoje no mercado.

Além disso, a minha percepção é completamente diferente da de que Java está se fechando e querendo ser a soluçõa unica.   As informações que leio é de trabalhos por parte da Sun de fazer com que sua JVM seja poliglota, ou seja,  seja capaz de trabalhar com diversas linguagens que não somente Java.  A prova e/ou reflexo disso é o JRuby, Groovy, Jython,  Scala , Clojures, etc.

Uma outra coisa é que essas mesmas pessoas que criticam Java, podem num futuro próximo, com uma nova tecnologia ter a mesmo comportamento que criticam hoje: de achar que só a tecnologia que dominam é capaz de resolver todos os problemas.

Para finalizar, Java é bom, desde que saiba usá-lo.  E hoje mais vale ser um programador que conhece diversas tecnologias pois assim poderá escolher a melhor para resolver seu problema.